Spark

jaja, pero cuál? yo no sé a que me dedicaré xDD Cuando esté el juego si que se compraran cosas para el escuadrón .

Jaja, yo que esperaba que montaras un taller de reparación conmigo Y que el resto nos trajeran los materiales para las reparaciones.

Descubre cómo se integrarán las reparaciones en el juego El espacio es un lugar hostil e incluso el más habilidoso de los pilotos necesitará que su nave sea parcheada de vez en cuando. Afortunadamente, hay una serie de opciones a disposición de los Ciudadanos para que puedan ponerlas de nuevo en marcha. El sistema de reparación de Star Citizen funciona junto al modelo detallado de daños que tiene el motor del juego para crear jugabilidad intuitiva y adictiva para aquellos jugadores que deseen seguir una carrera en la reparación de naves o para los pilotos que deseen realizar rápidas reparaciones de campo. La base para la tecnología de reparación en Star Citizen se encuentra en herramientas equipadas con láseres multi-propósito que pueden recortar el material dañado o sinterizar material de construcción que se inyecta en el bastidor del componente para reconstruir su estructura. Roles de Reparación Cualquier nave con capacidades de reparación tiene dos roles que deben ser ocupados para asegurarse de que es un trabajo de reparación correcto: el Operador del Brazo de Reparaciones y el Administrador de Tareas de Reparación. El Operador del Brazo de Reparaciones es responsable del control del brazo de reparación robótico. Acoplado sobre él se encuentra un láser multi-propósito y un sistema de inyección de materiales y este brazo es capaz de llevar a cabo todo tipo de tareas de mantenimiento. El brazo de reparación es el único método a disposición de los jugadores a la hora de restaurar una nave al 100% de su salud pero requiere de habilidad, conocimientos y coordinación con el Administrador de Tareas de Reparación para que tenga éxito. El Administrador de Tareas de Reparación comunica todo tipo de información de daños al detalle al Operador del Brazo de Reparaciones, señala que tareas de reparación deben ser llevadas a cabo y es responsable de la distribución de los materiales necesarios para reconstruir un componente o parte de una nave. ADMINISTRADOR DE TAREAS DE REPARACIÓN Para iniciar reparaciones en el taller, un Administrador de Tareas de Repearación debe primer usar su interfaz de evaluación de daños para recolectar información de daños y preparar las tareas de reparación necesarias. Valoración de los Daños Mientras esté usando su terminal, el Administrador de Tareas de Reparación puede acceder a los diagnósticos de daño de la nave siendo reparada. Esto muestra el estado de las partes de la nave, su casco, sistemas, armas y todas sus distintas conexiones. El jugador puede activar y filtrar entre las distintas capas, aislando y mostrando sus elementos respectivos. El daño que ha sido provocado al casco de la nave está representado sobre la transparencia de tu Realidad Aumentada como un mapa de calor: las zonas no dañadas están en verde, los daños totales o agujeros son mostrados en rojo y daños parciales señalados como una gradación de color entre ambos. Los bordes de los agujeros en el casco son resaltados para tener mayor claridad. Seleccionar las distintas partes mostrará su salud actual, así como los materiales requeridos para su reparación. Cuando se esté listo para comenzar el trabajo de reparación, el Administrador de las Tareas de Reparación selecciona la pieza deseada, abriendo el Panel de Materiales. Panel de Materiales Las reparaciones que se hagan en un taller requieren del consumo de materiales de construcción en bruto obtenidos a través de la Minería, Salvamento o Comercio. El Administrador de Tareas de Reparación puede asignar distintos materiales de acuerdo a la tarea de reparación que esté en marcha a través de su Panel de Materiales. Dependiendo del trabajo de Reparación, ciertos tipos y cantidades de Materiales son necesarios. Cuando un componente es seleccionado, estos requerimientos son indicados en la sección de Componentes de Reparación del Panel de Materiales como espacios que deben ser llenados desde el Stock de Materiales de la nave. Cada material es calificado en función de cómo de efectivo es cuando lo asignas a un espacio y cómo este afectará al procedimiento de reparación (discutido más adelante en la sección del Operador del Brazo de Reparación). Para obtener resultados óptimos, el Administrador de Tareas debe equilibrar los requerimientos de los Operadores de los Brazos respecto al valor de los materiales que están siendo utilizados. Una vez todos los materiales han sido asignados, el Operador del Brazo de Reparación puede comenzar el proceso de reconstrucción. Reconstrucción En el caso de que una pieza o un componente de una nave haya sido seccionado o destruído por completo, este debe ser reconstruído. para hacer esto, el Administrador de Tareas selecciona la parte perdida en su panel de Valoración de Daños y asigna los materiales de la manera habitual. Una vez que la composición ha sido confirmada la parte del bastidor perdida es automáticamente construída por el Brazo de Reparaciones: el proceso es completamente automático, usando patrones obtenidos a partir de la base de datos del terminal de reconstrucción. Después de que el bastidor haya sido construído, el jugador puede empezar a parchear sobre él la superficie de la manera normal. Antes de que pueda comenzar una reconstrucción, se debe limpiar el punto de anclaje de cualquier escombro que lo obstruya por el Operador del Brazo de Reparación. Mientras esté presente una obstrucción, esa parte aparece como un holograma rojo en la pantalla de valoración de daños, sobresaltando el material extraño para que sea eliminado. Capa de Daños de Realidad Aumentada sobresaltando los escombros que deben ser eliminados Punto de Anclaje limpio de una Pieza Reconstrucción del Bastidor OPERADOR DEL BRAZO DE REPARACIÓN Una vez que el Administrador de Tareas de Reparación haya escogido la pieza y la composición del material de reparación, el Operador del Brazo de Reparación comienza el proceso de reconstrucción y reparación. Al usar su terminar, el operador controla la posición del brazo y apunta con él de manera remota mediante una cámara instalada sobre el brazo. Para evitar hacer que los controles son muy complicados, su cabeza es controlada y apuntada directamente usando una solución IK (cinemática inversa) que hace que el resto del brazo se oriente sólo para seguir tus movimientos. El láser del Brazo de Reparaciones puede ser usado en los dos modos que tiene para llevar a cabo las distintas fases de reparación: Desmontaje y Parcheo. The Repair Arm’s laser can be switched between two modes to carry out the various necessary repair stages: Stripping and Patching. Desmontaje Desmontar el casco es vital para mejorar la integridad del casco de una nave que sólo ha recibido daños menores, ya que sólo se pueden parchear los segmentos perdidos. En modo desmontaje, el láser de alta potencia del brazo de reparación es usado para eliminar de manera limpia partes de la superficie de componentes sin causar daños estructurales al área circundante. Las superficies desmontadas son convertidas y recolectadas como un porcentaje de sus materiales en bruto. El desmontaje también es necesario cuando un componente u parte ha sido arrancada por completo. La reconstrucción completa de un componente requiere de un punto de anclaje limpio y esto obliga a que el operador elimine cualquier escombro que comprometa esa zona. Superficie sin desmontar Superficie desmontada Parcheo Parchear es el acto de reconstruir la superficie de una nave o componente y restaurar su integridad. Cuando te encuentras en modo de parcheo, el láser del Brazo de Reparación es reconfigurado para que "imprima" directamente el material sobre el bastidor o estructura de una nave o componente. Cuando se apunta con el brazo de reparación, un holograma wireframe es proyectado sobre él mostrando los límites del área dañáda sobre el que se puede imprimir. Sobre esta cuadrícula hay una malla de tracción de alta resolución que encaja con la superficie sin dañar, apoyando el material que se imprime sobre la nave. El Brazo de Reparación rocía un compuesto pulverizado mientras al mismo tiempo dispara un láser para calentarlo y unir el compuesto, creando una nueva superficie. A medida que la superficie de reparación es construída, la malla se contrae gradualmente para formar un nuevo borde de trabajo hasta que la zona está completamente restaurada. La resistencia de la nueva superficie depende de la cantidad de exposición que recibe por el láser. A medida que se construye la superficie, esta incrementa gradualmente su resistencia hasta que alcanza el 100%. Si el láser se mantiene centrado en esa área durante mucho más tiempo, la integridad se reduce a medida que la superficie se sobrecalienta. Esto crea un "punto justo" que el operador debe alcanzar antes de pasar a otra cosa para obtener la integridad más óptima. Cámara del brazo de reparación. El jugador puede escoger activar y desactivar el mapa de calor de los daños en Realidad Aumentada mientras parchea para recibir información en tiempo real a medida que se aproxima a este límite: la superficie va volviéndose progresivamente verde a medida que llega al 100% y luego pasa a volverse roja a medida que se sobre-expone la superficie al láser. Si una superficie es sobre-expuesta, el Operador del Brazo tendrá que volver a desmontar esa sección de la superficie antes de volver a intentar su parcheo. La composición del material de reparación, tal y como fue definida por el Administrador de Tareas de Reparación, determina el comportamiento de la superficie del parche a medida que esta es impresa: el máximo nivel de integridad, el tamaño del punto justo de integridad máxima y el ritmo al que la exposición afecta su integridad. Esto presenta un bucle para el jugador de riesgo frente a recompensa, donde la utilización de materiales baratos puede lograr el mismo resultado que los más caros, pero requiere de mucha más habilidad lograr esto con la tripulación de una nave de reparación, algo que obliga a que se tenga las habilidad de su tripulación en cuenta a la hora de pagar a los empleados y a la hora de asignar materiales. REPARACIONES DE CAMPO MULTI-HERRAMIENTA PERSONAL La Multi-herramienta es un objeto personal que está equipado con las capacidades de un Brazo de Reparación de taler pero a pequeña escala. Es capaz de desmontar y parchear, permitiendo que se logre una gran cantidad de reparaciones en tu nave, excepto una construcción completa de una pieza. Aunque las habilidades de reparación de la Multi-herramienta son las mismas que las de un Brazo de Reparación, el tamaño del láser y la poca cantidad de material de reparación que almacena significa que sólo es adecuada para rápidos arreglos y trabajos de parcheado para poder llevar la nave a una instalación de reparaciones de verdad. Multi-herramienta Personal DAÑO DE COMPONENTES Cuando tu nave recibe daños, parte de esos daños serán transferidos desde el punto de impacto en el casco hasta los componentes más cercanos de sistema y armamento. Estos componentes distribuirán entonces ese daño entre ellos y cualesquiera subcomponentes tenga conectados en su interior. Los subcomponentes son los distintos consumibles que son usados para hacer funcionar o mejorar un componente o el comportamiento de un sistema. En general, las reparaciones de campo de componentes consisten en desactivar cualquiera que sea el componente que está teniendo problemas, reemplazar los subcomponentes que estén dañados y luego activar el componente de nuevo. En componentes muy grandes, como aquellos que se encuentran en las naves capitales, puede que haya múltiples acciones implicadas en la activación o desactivación de un componente, incluyendo la derivación de energía o refrigerante a otras partes de la nave. Estas acciones puede que también requiera del uso de las computadoras de abordo de la nave. SUBCOMPONENTES Los subcomponentes proporcionan beneficios adicionales al componente al que están acoplados, permitiendo que se personalice todavía más la nave del jugador. Están divididos en tres categorías, cada una de las cuales proporciona áreas específicas de mejora. SOPORTES DE MÓDULOS Los soportes de módulos son paneles en los que se encuentran los distintos componentes que se usan para mantener los subcomponentes asociados en marcha. Estos pueden ser encontrados en el casco de la nave, tras escotillas de mantenimiento en naves pequeñas o situadas internamente en la sección de ingeniería de las naves multi-tripulación más grandes. Dependiendo del componente que esté instalado, son necesarios distintos tipos y cantidades de subcomponentes. Cada subcomponente está fabricado para que se pueda retirar y sustituir con rapidez, permitiendo que las reparaciones de campo se hagan lo más rápidamente posible. Si un jugador intenta quitar un subcomponente de un componente activo corren el riesgo de ser electrocutados y de recibir daños. Remplazar un subcomponente dañado es una cuestión de simplemente interactuar con el componente en cuestión. El jugador podrá entonces quitarlo, liberando el espacio que ocupaba. Si el jugador tiene en su posesión un repuesto, podrá interactuar con el espacio vació para situarlo allí. Los tipos de subcomponentes son universales entre todas las naves y componentes de la misma clase de tamaño, por lo que una barra refrigerante del cañón láser de un Gladius puede sustituir la barra refrigerante que está situada en el Generador de Escudos de un Hornet. Esto proporciona una gran cantidad de flexibilidad, permitiendo que los jugadores pasen elementos entre los distintos componentes según sea necesario a medida que los necesiten, así como abriendo la posibilidad a que se pueda parchear su nave utilizando piezas que han recuperado/encontrado. Los componentes de las naves más grandes, tales como la Idris o la Retaliator, pueden requerir de una gran cantidad de subcomponentes para que funcionen y/o subcomponentes de gran tamaño. Cuando están dañados, estos sistemas más complicados pueden llevar mucho más tiempo a la hora de ser diagnosticados y que se sustituyan sus subcomponentes dañados. Para llevar a cabo operaciones constantes, estas naves pueden contener sistemas auxiliares o de reserva. En caso de que haya una emergencia, los ingenieros pueden usar el terminal de su nave para redirigir energía al componente de reseva, permitiendo que la nave siga funcionando en ese aspecto mientras el ingeniero repara el sistema principal. Esto también puede ser hecho manualmente, en caso de que la terminal de ingeniería no esté operativa, cambiando físicamente todo el soporte del módulo principal y poniendo en su lugar el sistema auxiliar. FIN DE LA TRANSMISIÓN Extraído de http://www.ciudadanoestelar.com/j30/index.php/kunena/ciudadano/5751-diseno-reparacion-de-naves-y-mantenimiento

Friday, November 20th: Exploration Endeavor and Modules Carrack Saturday, November 21st: Piracy Caterpillar Herald Redeemer Cutlass Blue Sunday, November 22nd: Military Retaliator and Modules Starfarer Gemini Sabre Super Hornet Monday, November 23rd: Racing M50 Mustang Delta 350R Tuesday, November 24th: Aliens Khartu-al Banu Merchantman Reliant Wednesday, November 25th: Working Starships Reclaimer Genesis Starliner Orion Aurora LX Starfarer Thursday, November 26th: Mercantile Freelancer MIS Hull Series Constellation Phoenix Friday, November 27th – Sunday, November 29th: All Previously Offered Ships! From Friday through Sunday, all ships previously available during this sale will return. Pick up your favorite as soon as it appears, or wait until the finale to make your choice!

Solo si usáis fshost de chocolate software o similar admite diferentes sims.

Saludos, ciudadanos. Informe de desarrollo de "Star Citizen Alpha 2.0", cuarta semana... ¡Allá vamos! Bueno, esta última semana de trabajo en el juego ha sido divertida. Algunas veces puede resultar muy estresante, y entonces es fácil olvidarse de lo increíble que es el proyecto en el que estamos todos trabajando gracias al increíble apoyo que nos dais. Dejando todo eso aparte, ¡todos nosotros nos sentimos realmente muy contentos de ser parte del equipo que está haciendo que los sueños se conviertan en realidad! El Universo en Primera Persona será algo que no se ha hecho nunca antes en la historia de los videojuegos, por lo que cualquier proyecto tan ambicioso como el nuestro siempre va a representar un desafío. ¿Y a quién no le gusta un desafío? Nada que valga la pena resulta fácil. Star Citizen es un juego que estamos construyendo para que pueda ser disfrutado durante muchos y muchos años, y ahora estamos llegando a un punto de inflexión en un viaje muy especial que estamos haciendo todos juntos hasta la salida de la versión 2.0. Esperamos no tener que haceros esperar mucho más para vuestro primer contacto con lo que Star Citizen puede acabar siendo. Dedicar todos nuestros esfuerzos a esta gigantesca actualización fue una decisión dura, porque siempre existe el riesgo de que aumente las probabilidades de que se produzca un retraso en el desarrollo del juego, pero estamos convencidos de que tomamos la decisión correcta por el bien del proyecto ya que nos permitirá sentar las bases a partir de las cuales desarrollar el resto de elementos para largo plazo. ¡Una compañía editora de videojuegos tal vez no hubiera sido tan osada porque no tienen a la CMCH (Condenadamente Mejor Comunidad de la Historia)! ¡Poneos vuestra camisa de la suerte y coged vuestros tréboles de cuatro hojas porque la Ley de Murphy ha estado en plena vigencia esta semana! No, no se trata de un nuevo elemento del juego. Hemos sufrido un desafortunado percance: nuestro programador jefe del FPS se ha caído mientras iba en bicicleta y se ha roto la muñeca! Esto no lo teníamos previsto en nuestro calendario, por lo que al tenerlo de baja durante unas cuantas semanas, hemos tenido que hacer uso de algunos recursos de otros departamentos para que nos ayuden a conseguir que el 2.0 llegue a la línea de meta. Definitivamente, esto no es lo que nos hacía falta en este momento crítico del proyecto, pero son cosas que pasan. Pasando a noticias mas halagÁ¼eñas, casi hemos terminado nuestro proceso Excludibir, y sólo nos falta un informe más de Control de Calidad acerca de una serie de elementos del Gladius que no aparecían y provocaban un pantallazo negro en el tutorial del juego. Estamos arreglando eso y esperamos que no nos dé más problemas para la 2.0. Las nuevas IU para pantallas de naves de las que colgamos un vídeo la semana pasada fueron muy bien recibidas, y ese es el tipo de respuesta que nos anima aquí en la oficina y hace que nuestra comunidad sea un grupo de gente fabulosa para la que trabajar. Nunca estamos totalmente seguros de cómo va a ser recibido algo que hemos hecho hasta que lo enseñamos ahí fuera, por lo que la publicación de ese vídeo fue una buena manera de "meter un dedo del pie en el agua". ¡Ya hemos terminado las últimas funciones de código de las IU, por lo que ahora están siendo sometidas a prueba para asegurarnos de que hacer clic sobre todos esos botones hace realmente algo! Por favor, tened en cuenta que las secciones que aparecen en el vídeo identificadas como "Sistema desconectado" (System Offline") no serán funcionales en esta versión, pero lo irán siendo en futuros parches a medida que las vamos desarrollando. La forma en que los pulsos electromagnéticos afectan a los componentes está siendo implementada (NdT: en el original pone "the item component for EMP", lo que no me deja nada claro el contexto en el que lo dicen) y durante esta semana será probada a fondo, por lo que estamos esperando ávidamente los resultados de esas pruebas. El departamento de Diseño ha estado ocupado revisando los nuevos Modos de Vuelo IFCS - SCM (Maniobrabilidad de Combate Espacial), Precisión y Crucero. Todos estos modos están saliendo muy bien, pero siempre te sientes raro al empezar a probar un nuevo sistema de control. Suele llevarte tiempo familiarizarte con los cambios y queremos asegurarnos de que os daremos unos cimientos sólidos con los que os sentiréis cómodos y os lo pasaréis bien mientras nosotros seguimos desarrollándolos a partir de ahí. El peor bug de todos los bugs que han sido una espina clavada en nuestro costado durante la semana pasada ha sido la degradación de servidores. El equipo entero de Control de Calidad necesitó dos días para localizar este dichoso problema, pero en el momento en que escribo esto, uno de nuestros programadores acaba de proporcionarnos una forma de arreglarlo que esperamos que pronto será verificada en la próxima build para Control de Calidad. Este bug iba impidiendo de forma gradual que los jugadores pudieran entrar en un servidor del juego tras haber pasado cierto tiempo jugando, lo que despertó nuestras sospechas y nos hizo repasar toda la secuencia de eventos que había dado lugar a este problema para tratar de averiguar cuál era la causa. Era un bug difícil de reproducir porque para ello era necesario que hubiera durante horas una gran cantidad de jugadores. Al final logramos seguirle la pista hasta un problema que había con el selector de naves y las cuentas de los jugadores, y esperamos de todo corazón que la solución de nuestro programador sirva para reducir el número de problemas relacionados con este bug que hemos estado sufriendo en nuestros servidores. Éste ha sido un ejemplo perfecto de cómo una pequeña discrepancia en la build puede tener enormes consecuencias! Hablando de consecuencias, hemos encontrado en nuestras Release Builds unos cuantos problemas bloqueadores y que ya aparecen en la lista que damos a continuación, pero afortunadamente tenemos formas de sortearlos todos en nuestras Profile Builds, por lo que hemos podido seguir con nuestro trabajo. ¡Esto, no obstante, significa que la build todavía no es apta para hacerla pública! Los departamentos de Desarrollo, Producción y Control de Calidad están dándole caña a los problemas que nos quedan por resolver y probando cualquier solución creativa que nos permita algo tener lo suficientemente sólido para su publicación. Estamos tomando algunas decisiones difíciles respecto a qué debemos clasificar como de "obligada solución" para la publicación del 2.0. ¡El trabajo que estamos haciendo nos ayudará a minimizar las probabilidades de que tengamos nuevas consecuencias inesperadas innecesarias y al mismo tiempo haceros llegar lo antes posible algo con lo que podáis jugar! A continuación os damos de un resumen general de en qué han estado concentrados nuestros diversos equipos a lo largo de esta última semana... JUGABILIDAD E INGENIERÁA -Solucionado un problema importante que hacía que el rendimiento del servidor fuera empeorando gradualmente. -Solucionados fallos de memoria en la nueva zona del sistema cuando se destruían vehículos. -Se está trabajando en la solución de problemas con el viaje cuántico. -Se está trabajando en la solución de un problema que hace que varias naves que viajan al mismo punto de destino acaban apareciendo una dentro de la otra. -Se está trabajando en la solución de un problema que hace que seas teleportado al punto inicial del viaje cuando emerges del viaje cuántico. -Se está implementando y equilibrando un nuevo tipo de combustible: el combustible cuántico. -El combustible cuántico se va agotando al viajar a velocidades cuánticas y obliga a los jugadores a repostar o correr el riesgo de quedarse varados en lo profundo del espacio. -Se ha optimizado la red. -Se ha optimizado el rendimiento. -Se han solucionado una serie de bugs generales. IU (Interfaz de usuario) -Se han solucionado y corregido una serie de bugs. -Se ha quitado el mensaje emergente que aparecía para indicarte cómo curar a otro jugador cuando estás cerca de un jugador herido, ya que hemos eliminado temporalmente la habilidad de curar a otros jugadores hasta que se haya corregido el problema con la animación del medilápiz. ARTE -Se han solucionado y corregido una serie de bugs. ANIMACIONES -Se han solucionado y corregido una serie de bugs. El apunto con la mira se ha mejorado mucho, y tengo ganas de hacer más pruebas de combate del FPS por el exterior de las estaciones situadas en la zona de Armisticio. SONIDO -Se están mezclando y añadiendo las nuevas frases de diálogo que se grabaron -Se han diseñado nuevos efectos de reverberación en circunvalaciones, principalmente para espacios interiores. -Se está puliendo el sonido del mapa de Crusader en general. -Se está trabajando en mejorar el diseño de sonido para actividades EVA. -Se siguen mejorando los efectos de sonido de pasadas cercanas de naves. -Se siguen solucionando bugs generales. PROBLEMAS BLOQUEADORES -La degradación de servidores causan problemas de reaparición de jugadores (se ha presentado una solución). -El viaje cuántico sigue causando cuelgues en la versión de lanzamiento. -El jugador no puede coger un arma para el FPS en el Puesto de Seguridad Kareah en la versión de lanzamiento - ACTUALIZACIÓN: ¡Problema solucionado! -Al subir a naves pequeñas y medianas provoca que el jugador aparezca en las coordenadas de origen (0,0,0) en la versión de lanzamiento. -Hay casos difíciles de reproducir en los que el viaje cuántico no lleva al jugador hasta el punto marcado de destino en la versión de lanzamiento. -El repostado en CryAstro no funciona. Extraido de: http://www.ciudadanoestelar.com/j30/index.php/kunena/ciudadano/5724-informe-sobre-el-desarrollo-star-citizen-2-0-y-star-marine-14-11-2015

Que bonito el paisaje de la 2ª foto. ¿Es el BMS default o algún addon?

Todo depende del avión, la cessna no puede volar a gran altitud, así que olvidate de pillar aerovías de gran altitud, otra cuestión es lo que diga la normativa de si puede o no volar por aerovías que usan los reactores. Normalmente en aparatos pequeños se hacen las rutas usando VOR. Y sí, lo meten en el FMC o cargan el plan que tienen de vuelos anteriores que es lo habitual, y todo automático excepto despegue y aterrizaje, incluso captural la ILS para que les aterrice solo, unicamente cogen los mandos cuando están muy cerca de tomar tierra. Si eres un piloto privado tienes que entregar a la autoridad tu plan de vuelo, sea VFR o IFR, donde indicas con todo detalle la ruta que vas a seguir, por si no apareces en destino saber que ruta has tomado y buscarte, para ayudarte en caso de que haya tráfico en tu camino, etc. Si eres piloto de línea aérea tu compañía ya tiene a alguien encargado de eso después de haber hecho reunión previa al vuelo según el METAR, si el tiempo no es desfavorable se suele seguir siempre la misma ruta. Con un ATR no sé, pero diría que si no usan aerovías usan VOR. Con una avioneta tipo ultraligero por ejemplo no se puede superar cierta altitud por normativa, así que puedes hacer un plan de vuelo poniendo la star y luego puntos de interés (en aviación no recuerdo que nombre tienen), en algunas cartas aparecen tipo pico tal, pueblo tal, y añadir carreteras, ríos, una vez tengas la ruta hecha la vas siguiendo. Es lo que creo que hacen, pero no lo sé al 100%. De todas formas donde más información hay recopilada es en IVAO, mirate el apartado documentos http://www.ivao.es/piloto/flight_student.html Luego tu decides cuanto te quieres ceñir a la realidad.

Es que solo fui piloto de combate virtual una vez y no mucho tiempo, y fue con el E111 xD P.D: Me están dando ganas de volver jaja, quizás en unos meses.

Yo también creo que era de esa promo xD supongo que yo fui de esos de ir.... y no venir.... No sé si eras tu el que quería ser piloto de helicópteros de la policía. También recuerdo el día que coincidí con Madbird, su paciencia con los nuevos. Los dogfight con alguno de "la promo de la muerte" contra Serpi y Revi. (Era casi imposible derribarlos). Yo solia estar en las SEAD. Mi última VB1 con Revi cuando me tocaba aterrizar le hice una cobra y caí de culo al final de pista jaja.

D.E.P

¿Este despega en buster? https://youtu.be/RJC3ReOrqrU

Hay muchas aerolíneas que no usan IVAO o VATSIM, principalmente porque se necesitan unos requisitos para que te acepten como aerolínea, y también porque muchas aerolíneas prefieren un modo más tranquilo en procedimientos para sus pilotos. Un vuelo real con piloto automático, si no recuerdo mal, se carga una ruta realizada según lo visto en el METAR (si hay una tormenta se intentará volar a distinta altura o incluso coger un camino alternativo), todas las rutas de jets comerciales usan aerovías, estas pueden coincidir en algunos puntos con VOR o ¿DBM?. La información de la ruta se programa en el FMC, un ordenador en el que indicas el punto de salida del aeropuerto y el de llegada (SID STAR), la ruta Punto a punto de las aerovías. Las aerovías se pueden sacar de http://rfinder.asalink.net/free/ Un ejemplo de configuración de FMC: https://www.youtube.com/watch?v=mFKM7Gnik-8 Pero como te han comentado lo mejor es una aerolínea virtual porque pueden darte instrucción en directo.

Sí, lo tenia incluso subido el volumen boost a +10db, si lo ponía a +20 se escuchaban ellos mismos desde mis auriculares hasta el micro xD. A ver si tengo tiempo y pruebo los nuevos , estoy hecho polvo , ayer me vine de preparar una charla a las 3 de la mañana y la tenia a las 8 hoy, toy muerto jaja.

Eso es lo que tengo que probar jaja, que con los que tenía antes, no sé si por el micro o por el conector frontal del pc me escuchan bajo.

Lo ha puesto Arturo Cervera en el Facebook, que no sé qué nick usa en el E111 jaja.

Ya lo tengo, el sonido impresionante, y los bajos, parecia que estaba en una sala de cine con este vídeo https://youtu.be/4rWwNuNMpVs

Saludos, Ciudadanos: ¿Os he oído preguntar lo que ha pasado durante esta semana de desarrollo en la Alpha 2.0 de Star Citizen? Bueno, todavía hemos estado ajustando, puliendo y refinando cualquiera de los trozos de contenido mientras el resto del equipo iba al frente a luchar contra los bugs Bloqueadores y Críticos, ¡por lo que este informe semanal se va a leer más como un informe de Control de Calidad! ¡Estamos aportillando las escotillas mientras nos dedicamos a hacer algo de clásicos aplastado de bugs! La versión de lanzamiento de 2.0 está ahora cerrada y el equipo de Star Citizen está haciendo todo lo que está en su poder para hacer que esta versión esté lista para el combate para vosotros. Cada desarrollador tiene que ser extra-cuidadoso, comprobando su trabajo y haciendo que este sea revisado por sus compañeros de departamento en un informe de riesgos que debe ser aprobado por Producción antes de que se pueda unir a nuestra preciada versión de lanzamiento. Esta es una noticia muy bien recibida en Producción porque hemos encontrado algunos bugs muy frustrantes recientemente, y todo esto se añade a todos esos problemas más persistentes de los que podríamos prescindir. Que grandes sistemas tecnológicos como Grandes Mundos, EVA y Naves Multitripulación lleven más tiempo de lo que esperábamos no es una gran sorpresa, ¡y de de hecho es más o menos lo que esperábamos! Pero lo que no quieres (o por lo menos intentas evitar) es que haya retrasos en el lado logístico de la administración del proceso de una versión. Un problema que tuvimos recientemente fue nuestro sistema de exclusión - ¡Exludibur! - un sistema que utilizamos para configurar lo que está y lo que no en una versión dada (¡sin un sistema de exclusión, estaríamos lanzando cientos de gigabytes de elementos de juego sin optimizar, parcialmente completos en cada parche!) Así que cuando una parte de la geometría de entornos no había sido añadida a la lista de inclusión para la versión de lanzamiento de 2.0, ¡no fue una sorpresa para alguien que cuando fuese probada simplemente no estuviese en el juego! Y lo que es peor es que cuando esto sucede, el código sigue intentando crear la geometría que no está ahí, ¡le sienta muy mal y crashea! Todavía conseguimos probar cosas nuestra versión principal de desarrollo para progresar en nuestro trabajo, pero son cosas como estas las que toman tiempo de nuestra Producción y tenemos que centrarnos en hacerlo bien. Otro problema que podríamos haber evitado tiene que ver con nuestro nuevo Menú Principal que estamos haciendo para vosotros. Como puede que sepáis (o no), tenemos versiones internas de la versión que llamamos "Perfil" y que a veces pueden producir resultados de prueba ligeramente distintos a los que tendríamos en una versión del juego de "lanzamiento". Lanzamiento es la mejor para obtener las condiciones de prueba más auténticas, pero a veces necesitamos la versión de Perfil para tener algunas opciones de debuggeado o para esquivar problemas como una pantalla negra que estaba colgando el juego en una de las versiones de lanzamiento que tuvimos a principio de semana. La pantalla negra apareció porque se introdujo un nuevo menú principal que no estaba conectado en ese modo y por lo tanto no se podía probar. La versión de perfil pudo, sin embargo, esquivar ese problema y por lo tanto continuar nuestro trabajo y probar el resto del contenido del juego. De nuevo, esta es otra de las consideraciones que tenemos que tener en Producción y que nos tenemos que asegurar de eliminar para que el parche esté listo. Estoy seguro de que vosotros queréis oír hablar un poco más del nuevo Menu Principal, ¿no? Así que... la decisión de añadir un Menu Principal fue tomada para mejorar vuestra experiencia de usuario ayudándoos a introduciros en el juego con mayor rapidez en el inicio y también cuando salís de cualquier jugabilidad separada como un modo de juego de la simulación de Arena Commander. Ahora estamos permitiendo que el jugador escoja lo que quiere cargar con este nuevo menú, y así evitar esperar por contenido que no queréis acceder. Habéis estado hablando de esto en los foros, ¡por lo que os hemos escuchado y haciendo algo sobre ello! ¡Esperamos que lo aprobéis una vez que esté todo esto implementado en 2.0 y estoy seguro que lo sabremos si no es así! Sólo tened en cuenta que es una primera iteración. Hablando de noticias sobre la interfaz, hemos estado poniendo los últimos toques en las pantallas de las naves que veréis en los vídeos de actualización de esta semana, el cual os muestra la nueva y mejorada Avenger, Cutlass y Constellation. Estos son, de nuevo, una primera iteración con mucho más trabajo por hacer (por ejemplo, añadir la nave wireframe a la Avenger) y los mensajes de "System Unavaliable" deberían daros una indicación de las cosas molonas que vendrán en este sistema de múltiples capas que tendréis a la hora de administrar vuestras queridas naves espaciales. Así que eso es todo en el informe de esta semana. Esperamos que no necesitemos encontrar otro, o muchos, de estos informes porque estamos ciertamente "cerca" del lanzamiento de 2.0, pero la verdad es que es muy, muy difícil predecir cómo de cerca estamos. La lucha es dura en la trincheras de la 2.0, ¡pero tenemos un equipo increíblemente dedicado y lleno de talento que no podrá ser detenido durante mucho tiempo por los bugs! Así que gracias por vuestra paciencia y os mantendremos informados, pero por favor, ¡recordad que ESTÁ en camino! Aquí están los bugs de alto nivel desglosados para vosotros por el equipo... Jugabilidad e Ingeniería - Echando un vistazo a un bug de Viaje Cuántico en el que dos naves pueden salir la una dentro de la otra. - Mejorando el FOV de la pantalla de ingeniería en las naves multi-tripulación. - Continúa el trabajo a la hora de mejorar la experiencia EVA. - Mejorando el movimiento de las armas en combate FPS. - Arreglado un problema a la hora de morir en combate FPS, que deja un arma flotando en el aire. - Optimizaciones de rendimiento. - Arreglo de bugs Generales. Interfaz de Usuario - Añadido el soporte para tener una notificación de la recompensa de RECs. - Montones de pulido y arreglo de bugs en: Pantallas de las naves multi-tripulación Administrador de Misiones del mobiGlas Diario del mobiGlas Añadido un contador al respawn HUD de Viaje Cuántico Añadido un diseño virtual al panel de consolas de un ascensor de transporte. - Administrador de Misiones siendo actualizado en tiempo real, cuando lo tienes abierto. Arte - Pulido de entornos final y LODs. - Cambios de iluminación finales al mapa de Crusader. - Pulido final al daño de las naves, mapa de Crusader y EMP - Finalizando los LODs de la Avenger - Optimizaciones de la Retaliator. Animación - Refinando todavía más la locomoción básica del personaje. - Trabajo adicional para terminar las locomociones de pistolas. Sonido - Se ha hecho una sesión de diálogos y terminado, así que el master de estos archivos está en progreso. - Trabajando en mejorar el diseño de sonido de EVA. - Continuan las mejoras en los sonidos de las pasadas cercanas de las naves (ver vídeo adjunto). - Arreglando bugs en general. Problemas Bloqueadores - El marcador de Viaje Cuántico no está funcionando apropiadamente, por lo que el jugador no puede viajar a una localización de misión. - Se ha perdido la geometría de la estación debido a Excludibur (arreglado y verificado). - Desaparecida la geometría del ascensor de ArcCorp por culpa de Excludibur. - El servidor crashea cuando aparecen las naves Multitripulación. - Problemas de estabilidad en el servidor cuando hay más de 17 jugadores en el juego, ¡pero vastamente mejorado respecto a los 2 jugadores que teníamos hace dos semanas! - Pantalla negra y cuelgue en la versión de lanzamiento (arreglado y verificado). https://www.youtube.com/watch?v=U0MGRjNxRCQ ESTE VIDEO VALE MUCHO LA PENA https://www.youtube.com/watch?v=NiiV3Tt87Gk Extraido de: http://www.ciudadanoestelar.com/j30/index.php/kunena/ciudadano/5695-actualizacion-de-desarrollo-semanal-7-noviembre

Para los que estén en madrid: Experimentar una onda expansiva, probar puntería en una galería de tiro, someterse al polígrafo, análisis caligráfico de la firma o asistir a una sesión de briefing del FBI, es lo que podremos encontrar en este laboratorio. Más info: http://quantico-spain.com/2015/11/01/axn-abre-un-quantico-lab-con-motivo-del-estreno-de-la-serie-en-espana/ Si alguien va que nos explique que tal se lo pasó, y alguna fotillo jaja.

Que va, del dayz no sé, pero SC se va a terminar.

COMIENZO El parche 1.3 está fuera y la gente se ha vuelto un poco loca con los Buggies. Ben admite que están un poco bugueados; pero necesitaban hacer un test de carga de las mecánicas de colisión. 1.3 es un parche post-fusión de todas las versiones del juego que han estado en desarrollo paralelo los últimos meses, pero también metió la nueva zona de la Galería y un par de armas nuevas en Arena Commander. El equipo de la Comunidad irá a Austin en un par de semanas para grabar un ATV allí. También harán allí un evento en un bar de Austin para los mecenas de la ciudad. NOTICIAS CIG Santa Mónica - Arena Commander Eric Kieron Davies y Vince Sinatra. - Vince Sinatra, Jede de Control de Calidad en L.A., se ha unido al equipo de allí para ayudar a probar las mecánicas de la nave durante su diseño. - Se está trabajando en el anillo de atraque de la Constellation, de la mano de Olwin Bachiller, así como en los LODs de la nave. - Randy Vazquez está haciendo el diseño técnico de la Caterpillar. CIG Austin - Universo Persistente Jake Ross, que regresó de sus vacaciones en las Smoky Mountains - La UI de Compra está siendo mejorada entre Tony Zurovec, Zane Bien y Carl Jones, de la que pronto tendremos una previsualización de su aspecto y de como fluirá. - Casaba Outlet, la tienda de ropa, ya está toda hecha en whitebox y están haciendo el modelado final para que se puedan mover por dentro los jugadores bien y accedan a las estanterías de la ropa bien. - Trabajando en un efecto de "amortiguación" de la cámara en primera persona durante los emotes, ya que algunos eran realmente molestos al seguir la acción del personaje con la cabeza, especialmente bailando. CIG Manchester - Escuadrón 42 Tom Kewell y Simon Vickers - Tom ha estado trabajando en Star Citizen Alpha 2.0 en la mecánica temporal de reparación que van a meter mientras se desarrolla la mecánica real que tendrá el juego, en la que podremos ensuciar nuestras manos. Lo están haciendo así para que se repare rápidamente y se pueda explorar y testear el 2.0 por ahora. - Simon ha estado poniendo Eventos de Fondo en el sistema para mostrar al jugador el estado de este cuando lo visita, como cuando vas a localizaciones como una estación de reparación. Hay una posibilidad de que algo aparezca en esa localización, como una nave IA, que te muestre el tráfico normal de esa localización. En el caso de 2.0 encontraremos un conflicto entre los piratas y las fuerzas de la UEE, con apariciones de patrullas de la UEE o emboscadas piratas o mercaderes independientes buscándose la vida. Todas las IAs reaccionarán entre si de manera sistemática: las patrullas atacarán a los piratas si los ven o el pirata intentará atacar mercaderes para robarles su carga. Estas naves visitarán las estaciones de reparación de Tom de la misma manera que la de los jugadores, recibirán daños etc para crear un pequeño diorama de lo que será finalmente el juego. CIG Frankfurt - FPS/Motor Gráfico Brian Chambers - Brian nos hace un pequeño tour a las nuevas oficinas de Frankfurt a partir de 9:26-12:00. No mucho que comentar aquí, salvo que han aumentado la plantilla a 30 desarrolladores y en sus amplias y cómodas oficinas tienen espacio para 49. Saludos, ciudadanos. ¡Esta última semana ha pasado volando! Nos complace presentaros el segundo informe semanal acerca de en qué se ha avanzado tanto en "Star Citizen 2.0" como en "Star Marine". ¿Las novedades más molonas? ¡AHORA LAS NAVES SE PUEDEN PARTIR EN DOS (o más) TROZOS! Sí, los equipos de código y de diseño técnico han estado trabajando duro y haciendo que esta emocionante característica funcione en el motor del juego, y han conseguido finalmente implementarla... ¡por lo que a partir de ahora seréis capaces de reventar las naves en distintos trozos cuando les hayáis infligido daño catastrófico! Ahora podréis darles realmente candela a vuestros peores enemigos causándoles daños irreparables a sus naves, como, por ejemplo, partir una Constellation en cuatro trozos distintos. El sistema todavía necesita recibir un poco de cariño antes de que podamos ponerlo a vuestra disposición, pero en cuestiones de funcionalidad técnica, hemos hecho unos avances rompedores (¡perdón por el juego de palabras!). Todo el mundo ha estado puliendo detalles y corrigiendo bugs, y todavía nos están llegando algunos contenidos procedentes de varios departamentos, contenido que incluye más elementos de audio que suenan fabulosos. Nuestro especialista en diálogos ha estado en Pinewood Studios (famosos por las películas de James Bond y el juego "Privateer 2: the Darkening") y en SIDE UK para grabar más fragmentos de diálogo referentes a grabaciones de audio, que están resultando ser un elemento de exploración muy divertido de buscar. Todavía nos estamos peleando con el sistema EVA para conseguir alcanzar ese punto en el que nos parezca que está perfectamente terminado, pero al menos le estamos sacando más jugo a los sistemas de la nave en lo que concierne al comportamiento de la IA. La IA tendrá en cuenta ahora los nuevos encuentros y escenarios a los que los jugadores se enfrentarán en Crusader. Por ejemplo, la construcción del mapa está equilibrada para que si el jugador se aleja demasiado de la seguridad de las zonas de la UEE, puede que tenga algún mal encuentro, o a lo mejor tiene suerte y no sufre ningún disgusto. ¿Quién sabe? La belleza de todo ello es que es todo una jugabilidad con enfoque sistémica en la que cada encuentro posee su propio potencial único. ¿Y qué pasa con la parte relacionada con "Star Marine"? Con nuestras botas en el suelo, estamos viendo algunas mejoras notables en las animaciones de recarga de armas del FPS, apuntar con la mira y empezar a moverse y parar, por lo que estamos muy contentos de que todo esté empezando realmente a cobrar forma, y no sólo es que los personajes tengan mejor aspecto, sino que el entorno también lo tiene. El equipo de Entorno ha estado ocupado con las distintas estaciones espaciales en sus etapas finales de diseño artístico, y la Central de Carga Covalex justo acaba de recibir una pasada completa de iluminación, ¡por lo que estamos seguros que va a dejar apabullada a la gente! Crusader en todo su conjunto parece ahora mucho más vivo y con más interacción con los bots de reparaciones y la implementación de los sistemas de simulación de tráfico de fondo, ¡que servirá para darle auténtica vidilla al mapa con todos esos comerciantes y patrullas de la UEE deambulando de aquí para allí! Éste es otro de esos primeros pasos que Star Citizen dará con esta versión, ya que el universo empieza a cobrar vida poco a poco gracias a la creación de todos los sistemas que producirán de forma orgánica las economías y comunidades con las que podrás jugar. Por último, hay algunas grandes mejoras referentes al rediseño de las IU de las pantallas internas de las naves, rediseño que se ha hecho para que tengan en cuenta todas las mecánicas de juego nuevas asociadas a las naves multitripuladas. El equipo de diseño de IU está realmente emocionado por el aspecto que está adquiriendo todo, y cualquiera de nuestros lectores al que le guste trastear con aparatitos se sentirá entusiasmado cuando pueda por fin manejar la primera implementación de la pantalla de ingeniería, que permite un mayor control sobre la distribución de potencia y los sistemas de escudos de vuestras naves. Esta nueva pantalla, además, se centra en la funcionalidad para permitirte pasar tu atención de forma rápida y sencilla a cualquiera de las pantallas individuales que hay distribuidas en tu puesto. Las IU de estas pantallas necesitaba tanta consideración porque supondrán los cimientos de todo el resto del sistema durante los próximos años, y nos permitirán irles añadiendo cada vez más funcionalidad a medida que naves más y MÁS grandes van llegando al juego. A continuación tenéis un resumen general de en qué está atareado cada uno de nuestros departamentos... JUGABILIDAD E INGENIERÁA - Las naves llegan con mayor precisión al final de las sendas de vuelo de IA. - Las naves que siguen sendas de vuelo de IA utilizan mejor la esquina dinámica de obstáculos. - Se ha mejorado la conducta de huida de una nave cuyo caso haya sufrido daños graves. - Se ha mejorado el uso de misiles por parte de las naves. - Las naves son más precisas a la hora de esquivar obstáculos. - Se ha cambiado la relación entre los brazos del personaje y la cámara, lo que mejora el apuntado con la mira y los disparos desde la cadera. - Se han solucionado problemas con los saltos del jugador. - Se han pulido los conjuntos de movimientos de la pistola para que estén al mismo nivel que los del fusil. - Se ha mejorado el uso de las físicas de "muñeca de trapo". - Las partidas en red tienen ahora en cuenta el combustible cuántico. - Se ha añadido un test de colisión antes de iniciar el viaje cuántico. Sirve para informarte de si hay objetos entre ti y el destino programado. - Se ha añadido soporte para balizas de navegación para viaje cuántico descubribles. - Se ha mejorado/pulido la funcionalidad del dron de reparaciones. - Optimización de la red. IU (interfaz del usuario) - Mejoras en el HUD de viaje cuántico - Ahora hay círculos alrededor de los puntos de interés - Se ha añadido la cantidad consumida de combustible cuántico - Se ha añadido un mensaje de "fuera de alcance" se tratas de hacer un salto para el que no tienes suficiente combustible. - Casi todas las naves tienen ahora HUDs de viaje cuántico - Se ha entregado la primera iteración del gestor de misiones - 5 pantallas para el mapa de Crusader - Se ha entregado una implementación básica de las pantallas de Ingeniería con apartados de Potencia, Escudos, Resumen General y menú minimizado (hace falta ponerla a prueba). - Se ha pulido la pantalla de Ingeniería. - Implementación de "spawneo" de naves. - Mejoras en el gestor de misiones. - Ahora aparece una lista de las misiones completadas. ARTE - Nuevas iteraciones del Cutlas, el Retaliator y la Constellation en sus pasos finales de la cadena de montaje. - Mejoras finales del arte y efectos visuales para el entorno. ANIMACIONES - Más iteraciones de las interacciones con el entorno, EVA, movimiento y uso de armas en FPS, reacciones al sufrir impactos y morir, y secuencia de "dejarse caer". SONIDO - Sesión de grabaciones de diálogos para algunas frases adicionales y regrabado de algunas ya hechas antes. - Se ha empezado a trabajar en mejoras en el audio de las naves. - Implementación de más música para mejorar el "feeling" de cada zona y "venderte la escena". - Se ha trabajado en parámetros de "rigores del vuelo" que serán aplicados a tu nave bajo ciertas condiciones. - Se ha empezado a diseñar audio para esas condiciones. - Mejoras en el sonido de las armas y utensilios del FPS. - Se está ampliando la variedad de sonidos de pisadas que se pueden oír en cada superficie. - Se está trabajando en mejor las cualidades atmosféricas de las estaciones espaciales. BLOQUEADORES - A los personajes les faltan secciones interiores de sus cascos. - Las armas balísticas causan un cuelgue del juego y hay otros problemas de estabilidad que deben arreglarse. - El sistema de "tirar y empujar" parece estar en conflicto con algún otro sistema de control, ¡porque ahora mismo catapulta al jugador hacia lo más profundo del espaciooooooo! - Las partículas parecen dejar de renderizarse en algunas zonas con gravedad, ¡pero no en todas¡ ¡Esto hay que investigarlo! MIRANDO HACIA EL FUTURO ¡Uf, vaya semanita! Como podéis ver, estamos haciendo muchos progresos en lo que parece ser la versión más emocionante de Star Citizen hasta la fecha. Tras la publicación este mismo día (en el momento de colgar este artículo en la página de RSI) de la versión pública de "Star Citizen Alpha 1.3", ¡nuestro siguiente objetivo es la versión PTU de "Star Citizen Alpha 2.0"! No podemos esperar a que podáis explorar (y, para seros sinceros, ¡romper!) el Mini PTU. Todo el equipo está trabajando lo más duro posible para ponerlo a disposición de los backers para que puedan probarlo. Tened en cuenta que aunque durante esta semana nos hemos centrado sobre todo en la Aplha 2.0, el informe de la semana que viene traerá más detalles sobre "Star Marine". https://www.youtube.com/watch?v=CfMQ9DhLx9E Fuente: http://www.ciudadanoestelar.com/j30/index.php/kunena/ciudadano/5662-around-the-verse-episodio-2-05 http://www.ciudadanoestelar.com/j30/index.php/kunena/ciudadano/5652-informe-del-desarrollo-star-citizen-alpha-2-0-y-star-marine-23-10-2015

Actualizado

EL FUTURO DEL VUELO Desde el lanzamiento original del Arena Commander, hemos incrementado la velocidad máxima, reducido la disponibilidad de los posquemadores y reducido la potencia de los impulsores de maniobra. Aunque estos han tenido drásticos efectos sobre el juego, ninguno de estos han sido un cambio fundamental en la manera en que en realidad funciona el juego... ¡lo cual demuestra cuanto puede afectar a un sistema el equilibrado de unas estadísticas! Sin embargo, entre bambalinas, hemos estado trabajando en unos cambios más profundos al modelo de vuelo y estamos acercándonos al momento en que parte de ese trabajo pueda ser puesto frente a los jugadores. Modos de Vuelo (también conocido como IFCS 2.0) La característica nueva más ostentosa es los modos de vuelo adicionales: Precisión, Maniobras de Combate Espacial (SCM) y Crucero. Todos estos son perfiles de IFCS que hacen que el comportamiento de la nave se centre en objetivos muy diferentes como ajustes de muy baja tolerancia, acciones de combate y vuelo de larga distancia. Aunque sólo puedes usar uno de estos modos al mismo tiempo, acoplado/desacoplado y la colección de asistencias de vuelo todavía pueden ser utilizadas para mejorar todavía más su manejo. Modo de Precisión Cuando despegues empezarás en Modo Precisión. En Modo Precisión, la velocidad máxima se verá reducida de manera significativa y el empuje y aceleración son re-escalados de manera que se mejore el control cuando se maniobre en las cercanías de otros objetos. Esto hace que el aterrizaje y el despegue sean mucho más fáciles, pero también mejora el control en torno a otros objetos como asteroides, naves a la deriva o cuando te aproximes a otra nave en movimiento durante las maniobras de Repostaje en Vuelo o Abordaje. Modo SCM Una vez te hayas separado de los objetos que estén cerca y hayas alcanzado cierta velocidad querrás cambiar al modo de Maniobra de Combate Espacial. SCM es uno de los mayores cambios en el sistema de control de vuelo, pero superficialmente imita mucho las mecánicas de vuelo que tenemos ahora y a los que habéis acostumbrado en Arena Commander. El auténtico poder del modo SCM es que la velocidad máxima será calculada ahora de manera dinámica como una función de la fuerza y la masa: F/m * T = Velocidad Máxima en SCM. Hemos incorporado el cálculo de SCM de tal manera que es tu habilidad de detenerte por completo desde cualquier eje de giro (x o z) la que determinará la velocidad máxima a la que podrá volar tu nave. Esto significa que mejorar los impulsores de maniobra generalmente implicará que se permitan mayores velocidades máximas a través del IFCS. Además, esta velocidad es determinda por el mejor eje de giro de la nave, lo cual significa que el mejor control de deriva se obtendrá girando sobre el eje más fuerte, en vez de sobre el más débil. Cada nave tendrá una configuración distinta de ejes débiles y fuertes y es cosa del piloto aprenderlas y utilizarlas en su favor. Posquemador Hay otro emocionante beneficio a este cambio del SCM: Posquemador (afterburner). Mientras que la mecánica de impulso (boost) actual te proporciona mejor aceleración y control de deriva, el Posquemador te proporcionará una mayor velocidad máxima mientras se mantiene un control similar. Esto funciona así: en modo SCM la velocidad máxima es obtenida mediante tu habilidad de acelerar en una cantidad de tiempo. Ya que el impulso incrementa tu aceleración tu velocidad máxima también se incrementará. El Impulso tal y como funciona ahora mismo todavía está en este sistema, pero ahora los jugadores tendrán la elección sobre cómo quieren utilizar su limitada cantidad de combustible de impulso: en máxima velocidad para cambiar la distancia con rapidez o en una mejor capacidad de frenado para mejorar su maniobrabilidad. Modo Crucero Para el viaje a larga distancia en la misma zona local los Pilotos tendrán ahora la habilidad de utilizar el Modo Crucero. Si el límite de velocidad definido en SCM da al piloto control a cambio de velocidad, el Modo Crucero da al piloto velocidad a expensas del control. Y aunque la velocidad máxima es alta, la aceleración disponible no cambia, lo cual significa que alcanzar la máxima velocidad de Crucero llevará de más de 15-20 segundos, la velocidad de giro no escala con la velocidad y detenerte por completo llevará mucho más tiempo usando los retro-impulsores normales de la nave. Ya que las velocidades de crucero pueden alcanzar con facilidad x5 veces más velocidad que lo que puede controlar con seguridad el modo SCM, el IFCS fuerza el giro controlado para asegurarse de que los pilotos no se metan en derivas sin control. Esto significa que el morro de la nave está fijado al vector de velocidad y que las maniobras en modo Crucero sean más de ajustes de tu curso y menos en hacer giros. No hace falta decir que el Crucero no está diseñado para ser utilizado en combate, campos de asteroides o rutas espaciales con mucho tráfico. Por supuesto, siempre se puede utilizar el modo desacoplado para rotar libremente a velocidad de crucero. Los pilotos astutos descubrirán con rapidez cómo usar el modo desacoplado y el impulso para frenar con sus motores principales tan rápido como sea posible. De la misma manera, los pilotos descubrirán que intentar cambiar de dirección 90 grados usando modo desacoplado es un billete expreso al mundo de los sueños, ya que las altas fuerzas-g implicadas en tales maniobras te llevarían rápidamente a un desvanecimiento o a la eritropsia. Salto Cuántico Más allá de esos modos de vuelo estará el Viaje Cuántico, el único lugar en el que todas las naves están limitadas a la misma velocidad de 0.2c. Una vez que se ponga en marcha el Motor Cuántico, la nave acelerará rápidamente hasta alcanzar el límite de 0.2c - los pequeños saltos puede que nunca vayan tan rápido - con la propia nave experimentando una aceleración relativamente pequeña. A estas velocidades, pequeñas variaciones de ángulo resultarían en vastos cambios de trayectoria, por lo que aquí es donde las naves más lentas tendrán la oportunidad de escapar de las naves más rápidas que les persiguen. Por supuesto, viajar a estas increíbles velocidades es bastante peligroso, por lo que la computadora de la nave te sacará automáticamente de Viaje Cuántico si se detecta la posibilidad de una colisión o la nave tiene algún escudo bajado. Módulos de Control de Vuelo y Mejoras Uno de los objetivos de diseño que se presentó en el alba de este proyecto es el concepto del que el software de control de vuelo debería estar representado de manera física como un objeto en el mundo de juego. Pero hasta ahora el sistema IFCS ha estado completamente entre bambalinas y ha sido administrado a través de unos (relativamente) estáticos archivos XML. Se ha hecho mucho trabajo durante los últimos meses para preparar los bloques de parámetros del IFCS para su migración a el módulo de aviónica. que podrá ser cambiado por otro o mejorado. Cada módulo es utilizado con una nave específica y contiene todo los ajustes y parámetros que necesita conocer el IFCS sobre la nave para hacerla volar dentro de las especificaciones de ingeniería establecidas. Esto hace que para los diseñadores sea vastamente más sencillo el ajuste y equilibrado de las naves y de las mejoras de impulsores y nos da a nosotros más flexibilidad a la hora de dar características únicas a las distintas variantes de casco de las naves. Pero la parte más excitante es que los jugadores pronto podrán mejorar su software de control de vuelo junto a sus hardware de impulso para construir una nave que se ajuste a su propio estilo. Control de Movimiento El mayor cambio en el IFCS es su cambio a un sistema de control de tercer orden de movimiento. Antes de este lanzamiento, el IFCS ha usado un sistema de control por respuesta en su control de movimiento espacial. El perfil de movimiento para este sistema de control de respuesta (un controlador PI) es un sinusoide exponencialmente amortiguado. El gráfico 1 muestra tanto la aceleración como el control de velocidad a medida que la velocidad pasa de 0 a 100 m/s. Gráfico 1 Este es un sistema de control iterativo que no hace ninguna suposición sobre el estado futuro o pasado del sistema y simplemente actúa para suavizar el error entre el estado actual de la nave y el estado objetivo. Debido a esto, es muy apropiado para nuestras necesidades, ya que las condiciones de daño y las fuerzas externas inesperadas pueden causar movimientos impredecibles. Para complicar todavía más el asunto, debido a que el IFCS está limitado por la cantidad de empuje disponible por los impulsores de la nave, el auténtico perfil de movimiento del juego está limitado. Este perfil se puede ver en el Gráfico 2, con el perfíl sin límites mostrado detrás como referencia. Gráfico 2 El gráfico de la segunda imagen es una descripción bastante ajustada del actual control de velocidad en las naves de Star Citizen, tanto para el control lineal como el rotacional. Aunque hay múltiples ventajas en este perfil de movimiento, hay algunas desventajas significativas, incluyendo A) Una dificultad en predecir el futuro estado de la nave cuando se mueve bajo este control y una respuesta de control asimétrica con un tiempo de asentamiento extendido. En particular, los jugadores han indicado a menudo que el tiempo de asentamiento extendido que tienen las naves hace que el vuelo de la naves de Star Citizen parezca "descuidado". Para ocuparnos de estos problemas, el nuevo lanzamiento del IFCS empezará a usar un sistema de control de dos niveles. El primer nivel, el control de prealimentación (feed-forward), calculará el movimiento ideal que tendría la nave, mientras que el segundo nivel, el control de realimentación (feedback), proporcionará la corrección de errores que mantendrá la nave tan cerca del movimiento ideal como sea posible, incluso bajo una condición dañada o bajo fuerzas externas inesperadas. Así pues, el algoritmo de movimiento actual seguirá siendo parte del sistema, proporcionando la misma tolerancia a los errores, pero no será ya el perfil de movimiento dominante (excepto si se encuentra bajo un error del sistema extremo). El sistema de control de prealimentación usará el movimiento ideal de tercer orden, tal y como indica el Gráfico 3. Gráfico 3 Al contrario que el algoritmo de retroalimentación, este perfil de movimiento es completamente predecible. En cualquier momento, se sabe cuando tiempo tardará la nave en llegar a una nueva velocidad o posición desde cualquier conjunto de condiciones iniciales. También se podrá ajustar la fase de incremento de aceleración para que las naves tengan un movimiento natural y suave, sin el excesivo comportamiento de ajuste que tiene el actual sistema de control. En la práctica, esto resultar en que habrá un abanico de comportamientos mucho más amplio, desde una respuesta potente y nerviosa como la de un coche deportivo, a una menos ágil pero suave, como la de un coche de lujo. El ritmo de cambio de la aceleración se denomina como "arranque" (Jerk), y es esencialmente la aceleración de tu aceleración. Una manera fácil de entender lo que es el arranque es pensar en cómo conduces tu coche. Cuando frenas tu coche para que se detenga por completo aplicas una cantidad constante y firme de deceleración y la frenada es mucho más suave y cómoda. Frenar suavemente es una acción con bajo arranque, mientras que pisarlo a fondo e una acción de alto arranque. Como referencia, el gráfico número 4 muestra el típico movimiento de segundo orden (aceleración constante, velocidad linear) utilizado en muchos juegos. Gráfico 4 Aunque el movimiento de segundo orden es un modelo de control mucho más sencillo, proporciona un movimiento de nave muy rígido y mecánico. El sistema de tercer orden nos permitirá ajustar las naves para que sean tan rígidas o suaves como necesitemos que sean. Equilibrado El equilibrado del vuelo de naves es una de las tareas más delicadas y difíciles que tenemos en este proyecto. El movimiento a un sistema del tercer orden y la adición de un modo de velocidad dinámica determinado han requerido de una re-equilibrio prácticamente desde cero de las características de control de las naves. Esto significa que cada una de las naves probablemente se notará muy distinta de lo que solíais sentir en el Arena Commander. Se ha tenido mucho cuidado, asegurándonos de que cada una de las naves retuviese su propio lugar en relación con las otras naves del universo. Somos conscientes de que cualquier cambio de esta magnitud va a iniciar un vivo y apasionado debate entre lo viejo y lo nuevo, pero estamos seguros de que los cambios nos permitirán hacer que las naves parezcan más reales y que esto les permita tener una personalidad más única de lo que antes tenía y al mismo tiempo se les proporcione un control más preciso. El cambio a los arranques significa que las acciones erráticas que se utilizan para hacer maniobras evasivas sean nerfeadas de manera natural, ya que ahora el sistema es ligeramente más lento a la hora de tomar acciones contrarias, mientras que las órdenes dedicadas, como las que se usan para lograr un deslizamiento, no se verán muy afectadas. El movimiento de tercer orden también es algo mucho más natural para el cerebro humano, así que el control será más intuitivo y por lo tanto las sobre-compensaciones serán menos necesarias. Ahora que el arranque está disponible como un nuevo parámetro, un nuevo comportamiento de "vuelo estabilizado" está a nuestra disposición. Esencialmente, esto significa que al poner un pequeño valor de arranque en un motor este pueda ser ajustado para que tenga un alto Valor de Carga relativo a su tamaño, permitiéndonos crear naves - como la serie-Hull o la Aurora - capaces de transportar mucha carga sin que se conviertan al mismo tiempo en las naves más rápidas del universo cuando no están cargadas. Y, aunque las naves serán más rápidas sin carga que con carga, podremos configurar naves distintas para que tengan diferentes niveles de pérdida de rendimiento cuando se vaya aumentado su carga. La primera pasada que lancemos al PTU será simplemente eso: una primera versión. La intención es que indique el tono general en que se dirigirá cada una de las naves, no su destino final. Como siempre, continuaremos probando y ajustando, y estaremos observando vuestros comentarios para ver si nosotros necesitamos ocuparnos de algún caso extremo o alguna consecuencia no esperada. Hay algunas cosillas más que vendrán como consecuencia a estos cambios, pero por ahora, hablemos de la deriva de empuje (thrust shunting) El Indomable Will Deriva (ndt: Good Will Shuntin, lo siento, el juego de palabras aquí con The Good Will Hunting no tiene mucho sentido XD) La Deriva de Impulso es el proceso mediante el que un empuje es generado en el motor principal y luego redireccionado a través del sistema de conductos de la nave hasta llegar a las distintas toberas (o "mavs", tal y como la comunidad los ha apodado, ndt: de maneuvering thrusters, impulsores de maniobra) a través de los cuales se usa la fuerza. Esto significa que los motores principales serán mucho más importantes ahora de lo que nunca hemos visto en Arena Commander, y más adelante, significará que podemos tener salas de máquinas enteras en nuestras naves capitales. En vez de tener motores repartidos por toda la nave ahora tendremos simplemente unas toberas accionadas, así que si el motor principal es dañado los impulsores de maniobra dejarán de funcionar. Cuando esto sucede, las naves tendrán giroscopios internos que podrán ser usados en caso de emergencia o para maniobras de intensidad super-baja, pero serán débiles y lentos. Lo más fantástico de esto es cómo esto abre nuevas oportunidades a la hora de dañar los comportamientos de vuelo de las naves. Un conducto de impulso dañado reduciría proporcionalmente el impulso disponible en esa tobera, y podría incluso introducir impulso no pretendido en el punto de impacto. Las propias toberas tendrán clasificaciones de calor y potencia, limitando la cantidad de empuje disponible - un límite que podrías exceder, aunque bajo tu cuenta y riesgo. El resultado es un equilibrio de comportamientos de vuelo que se refuerza por el propio diseño de la nave y el estado de sus componentes, comportamientos que un piloto habilidoso podrá llevar a su límite para cabalgar la delgada línea que separa la victoria de la catástrofe. Error de Impulsores y Turbulencia Hay muchas maneras en las que el estado actual de la nave puede desviarse del estado ideal solicitado por el IFCS. Hasta este momento hemos permitido que el sistema de control tenga un control perfecto bajo condiciones ideales, y esto crea un movimiento demasiado mecánico y a menudo de aspecto "muerto". Con el nuevo lanzamiento, esto ya no sucederá. Siempre habrá algún nivel de error en los impulsores y el sistema en tu control de vuelo. Esto se manifestará como una turbulencia menor bajo condiciones operativas ideales, pero se volverá mucho más extremo cuando los impulsores sean dañados, se sobrecalienten u otros factores. El gráfico número 5 indica una muestra de un perfil de velocidad del tercer orden. El IFCS debería solicitar empuje al sistema de impulsores para lograr este movimiento. Gráfico 5 Pero, debido al error de los impulsores, el cual puede incluir una serie de cosas desde un vector o potencia de empuje incorrecto, un vector o empuje inestable, etc, el movimiento real de la nave se podrá desviar del movimiento ideal. El siguiente gráfico muestra un ejemplo extremo de un error aleatorio en los impulsores que causa que la velocidad de la nave se desvíe de la velocidad ideal en una transición desde los 0 a los 100 m/s. Debido a los errores que tienen lugar durante las aceleraciones aplicadas (todas las acciones de una nave son finalmente aplicadas como aceleraciones, nunca directamente como correcciones de posición o velocidad) a lo largo del tiempo, la velocidad final lograda durante un cambio en la velocidad de la nave puede ser significativamente distinto del que se pretendía. El IFCS solicitó la velocidad de más arriba y obtuvo la mostrada en el gráfico número 6. Gráfico 6 Aquí es donde el sistema de retroalimentación original entra en juego. Este compara el estado actual de la nave y lo compara con el estado pretendido y genera aceleraciones correctivas adicionales para mantener el movimiento tan cerca de lo ideal como sea posible. El ejemplo mostrado en el Gráfico número 7 es para la error en la velocidad y la corrección de retroalimentación, pero un ejemplo más obvio en el juego se encontraría en el control de posición. El IFCS tiene un sistema de control de reacción (RCS, reaction control system) que mantiene la posición de la nave tal y como ha sido indicada por el piloto (el marco de control). Debido al error de los impulsores, así como otros factores externos, la posición real de la nave se puede desviar de la posición ideal. El RCS utiliza el sistema de control de retroalimentación para generar impulso y mantener la posición de nave en su posición pretendida. En la práctica, la turbulencia de los impulsores generada por un rendimiento de impulso imperfecto generará una pequeña cantidad de juego de impulsores en el morro de la nave, especialmente cuando se disparen los impulsores a máxima potencia y cuando se intente pasar a un estado inmóvil. Pero, de nuevo, el objetivo es que este nivel de errores sea sutil a no ser que se encuentre bajo condiciones de daño extremas. Esto gira más en torno a la estética del movimiento más que en torno al comportamiento de vuelo. Gráfico 7 Listo para el Combate Al final, la experiencia de Star Citizen es una combinación de todos sus sistemas, así que para explicar el vuelo de verdad, tenemos que hablar también sobre el combate. El objetivo del combate en Star Citizen es proporcionar acción frenética y rápida mientras al mismo tiempo se recompensa la planificación y las tácticas astutas. Esto significa cosas distintas en las diferentes escalas de naves - desde las intensas escaramuzas de los cazas monoplazas, a las batallas de maniobras de giro estilo SGM para poner todas las armas sobre el enemigo en las multitripuladas, o hasta llegar a las guerras de desgaste y situación de las gigantescas naves capitales - cada una ofreciendo su propio sabor al combate. Aún así, la filosofía para todas ellas es básicamente la misma: el combate es más divertido cuando se está jugando con diferentes niveles de riesgo, recompensa y entrega. Para la mayor parte de las naves, el mínimo denominador común de cualquier orden es la rotación. Los límites de seguridad de la tripulación limita que las naves realmente grandes hagan giros agresivos, pero para las naves más pequeñas, el giro es mucho más fácil. Ofensivamente, esto hace que la puntería sea más importante (de nuevo, con rendimientos decrecientes en función a la escala), pero defensivamente, los pilotos habilidosos intentarán tomar los impactos que no se pueden evitar donde sus escudos y blindajes son más fuertes. El manejo de la rotación se mejorará con la adición del modo de estabilización de manejo (Ndt: input stabilization mode), el cual restringe las rotaciones a su menor índice máximo disponible, eliminando una gran parte del error de escala en el marco de control. Las propiedades de la nave no se ven afectadas por esto, por lo que las maniobras todavía favorecen de manera realista un eje en particular de acuerdo a su diseño, pero el propio manejo es mucho más predecible e intuitivo. Las naves son diseñadas generalmente para que se favorezca el uso de los motores principales, aunque los índices de potencia de estos son en su mayor parte lo que crean la personalidad de cada nave. Esto significa que el deslizamiento, como hemos visto en los parches más recientes, y las maniobras de vuelo requieran algo más de planificación, incluso con el uso del modo de impulso. Esto hace que disparar sea de nuevo más fácil, pero recibir daño es también un gran parte de la experiencia de Star Citizen y es algo que apoyamos a todos los niveles. La elección a la hora de incluir múltiples componentes de cada tipo nos permite tener una degradación de capacidades mucho más significativa y que las naves sigan estando operativas a niveles de daño mucho mayores. Tras la lucha, tu nave estará llena de cicatrices de su última aventura. O, si las cosas se ponen feas, serás capaz de reparar las naves sobre la marcha y hacer triage de los daños que se vayan aplicando. Será probablemente una buena idea que te ocupes de esos conductos de disipación que fallan antes de que provoque un escape descontrolado del motor y una fusión total del reactor de tu planta de energía que vuele tu nave por los aires (te estoy mirando a ti, Connie...). Con la habilidad de las naves de recibir más daño vienen mayores niveles de compromiso, lo cual significa un cantidad mayor de administración de cosas como el combustible, el calor, y las fuerzas-g. Cuantos mayores atajos tomes, más acorralado te encontrarás. Los capitanes tendrán que considerar el riesgo a largo plazo de la recompensa a corto plazo si quieren salir victoriosos. Equilibrio Por supuesto, todas estas cosas al final parten del equilibrio para el apoyo a estos sistemas, y el equilibrio es un proceso largo y profundo. Llevará algo de tiempo conseguir que el equilibrio sea el apropiado, pero el objetivo es que se aproveche de los puntos fuertes de cada escala, y de las oportunidades que permitirán en su jugabilidad. En las naves más pequeñas, la maniobrabilidad es la reina, así que la ventaja se obtiene forzando a tu oponente a tomar más riesgos, pasarse de listo y hacerse vulnerable a un ataque mortal. La rotación es sencilla en el espacio, por lo que podéis estar seguros de que cualquier nave a la que le dispares te disparará a ti poco después. Una de las razones para esto es la simples físicas, ya que a medida que las naves se vuelvan más masivas el empuje necesario para ofrecer rotaciones rápidas escalará drásticamente, y por razones de retroalimentación de control y de manejo funcional, las rotaciones de nuestras naves tendrán menores posibilidades de error que las traslaciones. Las naves multi-tripulación podrán permitirse tener mayores períodos de vulnerabilidad, ya que las próximas mecánicas de reparación, manipulación de escudos y enrutamiento de conductos ofrecerán a una nave bajo ataque múltiples maneras de mejorar su situación y cambiar el rumbo de la batalla. A medida que estas naves se vuelvan cada vez más grandes, la jugabilidad empuja cada vez más la aparición de un pensamiento táctico más exigente, con la administración de los recursos de la nave y su posicionamiento convirtiéndose cada vez más en las preocupaciones más importantes de una lucha. Un objetivo clave de este tipo de combate es evitar que el éxito o el fracaso se conviertan en algo demasiado binario, o permitir que la batalla sea determinada por cada pocos (incluso pequeños) errores. A un nivel fundamental, Star Citizen es un juego en el que combate de nave a nave debería seguir siendo divertido y justo aunque una nave de transporte se viese atacada por piratas, una nave capital por cazas, ya que la pérdida de propiedades y vidas tienen un precio muy alto. No ganarás siempre y cuando sufras una pérdida, queremos que se perciba como que al final fuese una cuestión de habilidad. Queremos que esté basado en tu habilidad, pero también queremos que exista una sensación de progresión en el Universo Persistente. Un Hornet F7C debería ser una nave objetivamente mejor que una Mustang Alpha, pero las diferencias de potencia no deberían ser tan extremas que un piloto de Mustang no puede derrotar jamás a un Hornet: sólo sería una lucha más desafiante. Star Citizen es un juego sobre elecciones, así que cada vez que abandones tu hangar tendrás que decir qué naves quieres pilotar, qué equipo quieres instalar, a quien escoges como tripulación e incluso dónde y cuando almacenarás carga. Cada nave tiene su personalidad, cada nave su ventaja y su desventaja: cada camino tiene sus peligros. El objetivo no es hacer que sea todo para todo el mundo, si no crear un ecosistema en el que los jugadores puedan encontrar la mezcla apropiada para ellos. Algunos preferirán especializarse, y en la muy estrecha ventana de su especialidad encontrarán el éxito: otros preferirán ser autónomos y encontrarán una variedad de configuraciones que se ajuste a los distintos obstáculos que se encontrarán. Estas elecciones lo afectan todo, desde el consumo de energía a la carga de calor, hasta llegar a lo rápido que vuela una nave o cuanto se desliza. No hay una nave perfecta: sólo la nave perfecta para ti. Ášnete a la discusión aquí. FIN DE LA TRANSMISIÓN Extraído de: http://www.ciudadanoestelar.com/j30/index.php/kunena/ciudadano/5663-star-citizen-alpha-2-0-cambios-del-modelo-de-vuelo#125176

Por eso digo, 2 altavoces son y serán 2.1, que luego que si por software emulan 7.... incluso si tuviera 7 en el mismo auricular la procedencia sería desde dos fuentes distintas (stereo), no de 7. Tacens creo que es española, ha tenido últimamente bastante éxito con fuentes, cajas, teclados... Creo q lo voy a pillar, peor que los actuales no creo q sean.

Muy buenos comentarios e investigación.