Fotogramma di ritardo dell'emettitore

Anche questo non è propriamente un problema di retrocompatibilità, ma era presente in Early Access. Abbiamo ritenuto che valesse la pena illustrarvelo qui. Gli emettitori hanno un fotogramma di ritardo perché, quando l'oggetto viene clonato dal riferimento, questo ha bisogno di un fotogramma per far funzionare la logica che contiene e per verificare che tutto sia a posto. 

Un esempio:

immaginate di avere un interruttore e una lama rotante. L'interruttore attiva la lama rotante. Quando si seleziona questo congegno come riferimento di destinazione di un emettitore, la lama rotante esiste ancora nella scena come oggetto di riferimento per l'emettitore, ma è ora spenta. 

Quando si emette un oggetto, il gioco fa letteralmente un'operazione di clonazione sul riferimento.  Quindi ora avete una copia dell'interruttore e della lama rotante ma la lama è spenta (interruttore non attivo). L'emissione di oggetti avviene in ritardo nel fotogramma rispetto al codice che invia i segnali lungo i cavi. Quindi se dovessimo mostrare gli oggetti emessi nel fotogramma nel quale sono stati emessi, si vedrebbe una lama ferma per un fotogramma e poi nel fotogramma successivo, dopo che il segnale dell'interruttore è sceso lungo il cavo, questa inizierebbe a girare.  Quindi, per evitare problemi come questo (e altri molto più complicati che coinvolgono diversi gadget, timeline ecc.) gli oggetti non vengono mostrati nel primo fotogramma nel quale sono stati emessi.  Essi non producono effetti fisici su quel fotogramma e non eseguono la logica (zone di attivazione/raycast ecc.).

C'è un’ulteriore accortezza riguardo al secondo fotogramma: se anche l'emettitore è in movimento, quando l'oggetto appare diventerà evidente il fotogramma di ritardo, perché l'oggetto apparirà dietro all'emettitore (ricordate i proiettili che escono dalle navi).  Per compensare questo problema, gli oggetti emessi vengono spostati all'ultimo momento nel punto in cui sarebbero stati emessi se l'emettitore avesse emesso questo fotogramma!  Anche tutte le velocità sono ricalcolate in base a quello specifico punto.

In "Wildfire" il personaggio perde due vite alla morte. Ciò è dovuto al fatto che il personaggio è rigenerato da un emettitore. La logica all'interno del personaggio emesso non riesce a comunicare sul primo fotogramma, provocando così una seconda uccisione del personaggio da parte del sistema.

Timeline emesse: Non abbiamo ancora trovato un esempio di questo nei contenuti della community, ma noi stessi ci siamo imbattuti in questo problema, ed è un perfetto esempio di questo ritardo. Inoltre, è l'esempio perfetto per visualizzare questo comportamento dell'emettitore.

Un gadget (ad es. una porta NOT) sul primo fotogramma di una timeline che viene emessa non riuscirà ad attivare nulla.

Se si sa di avere a che fare con questo, la cosa più semplice da fare è togliere la porta NOT dalla timeline in modo che inneschi qualsiasi evento logico non appena la logica diventa attiva. Se occorre che l'evento sia un impulso, potrebbe essere necessario aggiungere un manipolatore di segnale.

Info cerchiate

La Guida utente di Dreams è in continuo sviluppo. Controlla gli aggiornamenti, perché continueremo ad aggiungere ulteriori risorse di apprendimento e articoli.