Am încercat să fac o căutare în documente și am verificat structura peretelui 4, dar nu am găsit nimic. Mă întreb dacă există vreo modalitate de a declanșa o funcție care să ruleze înainte ca nava să fie descărcată, deoarece jucătorul decide să se întoarcă la meniul principal, stația de urmărire sau centrul spațial.

efectuați

Distribuiți linkul

Problema este că, de îndată ce piesele sunt descărcate, procesorul kOS nu mai este simulat, deci scriptul nu va rula.

Din această cauză, cred că cel mai bun lucru pe care îl puteți face este să vă monitorizați diferența și viteza relativă de la nava activă, când aceasta începe să se apropie de distanța de ambalare, l-ați declanșa pentru a rula codul înainte de descărcare.

da, trebuie să fie o abilitate kOS încorporată, dar vreau să mă asigur că nu am trecut cu vederea înainte de a trimite o cerere de funcție github

trebuie să fie o abilitate kOS încorporată

Nu că nu pot vedea de ce ar putea fi util, nu văd doar un caz de utilizare în care același lucru ar putea fi realizat în alt mod.

S-ar putea să fiu închis la aspectul greșit al acestui aspect, dar se pare că dacă ai vrea să actualizezi starea navei tale pentru a fi actuală când ai plecat, ai putea să o actualizezi când starea s-a schimbat și să realizezi același lucru (deși cu mai multe scrie decât dacă l-ai face DOAR la ieșire). În ambele cazuri, acest lucru ar putea să nu fie relevant atunci când nava dvs. se reîncarcă, deoarece nu va fi funcționată, în timp ce nu este activă.

când părăsesc scena zborului sau schimb navele, vasul activ are nevoie pentru a-și stoca datele volatile. În acest moment trebuie să-mi amintesc să fac asta manual. Nu există nicio modalitate de declanșare automată, deoarece AFAIK nu are nicio modalitate de a spune când utilizatorul iese din scena zborului sau schimbă navele. Ar trebui să fie ceva de genul unei funcții de apel invers încorporate pe care o puteți defini pentru ca kOS să ruleze înainte de schimbarea scenei

Sau, adăugați posibilitatea ca structura cu peretele 4 să declanșeze schimbarea scenei, astfel încât să puteți crea propria comandă de ieșire care să se ocupe de orice activitate este necesară înainte de comutare

Corect, dar cred că am reușit să împart acest lucru împărțind datele în două categorii: date care pot fi reconstruite la pornire și date care nu pot. Salvez lucrurile pe care nu le pot reconstrui atunci când se schimbă, iar restul le reconstruiesc din asta.

Cele mai multe date volatile se încadrează în categoria anterioară, ocazional va trebui să economisesc niște pesmet din unele dintre bucățile mai puțin volatile din acesta pentru a le reconstrui. Cu toate acestea, în cea mai mare parte, datele volatile nu sunt foarte utile la repornire tocmai pentru că a fi volatile implică faptul că datele istorice sunt de mică relevanță pentru starea actuală. Când reiau zborul mai târziu, nu mă pot baza pe ultima înregistrare disponibilă a datelor mele volatile pentru a fi exactă sau chiar relevantă pentru situația mea actuală.

Nu sunt de acord că a avea acel cârlig de apel invers ar fi convenabil, cred că nu reușesc să vă văd cazul de utilizare în care este absolut necesar.

Cred că nu este absolut necesar, dar îl caut în continuare înainte de a lucra fără el. Și aș dori în continuare să mă descurc când este iminentă o schimbare de scenă sau navă, nu doar pentru date ascunse, acesta a fost doar exemplul meu imediat