Oddziel brakujące sceny od brakujących odniesień do zasobów
Projekt Unity można pomyślnie otworzyć, gdy brakuje ważnych prac. Możesz zobaczyć pustą scenę, brakujące scenariusze, różowe materiały lub obiekty, których odniesienia zostały zerwane. Nie wszystkie te objawy oznaczają, że podstawowe pliki zostały usunięte. Zacznij od ustalenia, czy utraciłeś zapisaną scenę, zasób, jego metadane lub środowisko, które pozwala Unity poprawnie zinterpretować projekt.
Na przykład model może przetrwać na dysku, gdy znikną jego oryginalne metadane. Unity może następnie przypisać nową tożsamość podczas importowania modelu, pozostawiając nierozwiązane odniesienia do istniejących scen. Wymiana modelu na identyczny wizualnie egzemplarz może nie naprawić tych referencji. Najpierw zachowaj projekt, a następnie poszukaj pasujących oryginalnych plików i ich powiązań, zamiast gromadzić pojedyncze zasoby bez kontekstu.
Zachowaj to, co jest wciąż otwarte
Jeśli żądana scena pozostaje otwarta i zawiera przydatne, niezapisane zmiany, zapisz ją pod osobną nazwą odzyskiwania przed zamknięciem edytora. Zachowaj także wszelkie niezapisane zmiany w skrypcie lub zasobach, korzystając z odpowiedniej kopii. Unikaj naciskania ogólnych akcji odrzucania lub cofania, dopóki nie zrozumiesz, które bieżące zmiany mają znaczenie. Próba odzyskiwania nie powinna usuwać jedynej wersji sceny na żywo, którą nadal możesz sprawdzić.
Skopiuj cały dostępny projekt do zdrowej lokalizacji przed zmianą jego struktury. Dołącz źródłowe foldery Assets, Packages i ProjectSettings wraz z innymi danymi wejściowymi specyficznymi dla projektu. Zapisz wersję edytora i zainstalowane zależności. Trzymaj wygenerowane skrytki osobno w swoim ekwipunku, ale nie usuwaj niczego z jedynego, który przetrwał, projektu podczas diagnozowania strat. Na szczególną uwagę zasługują foldery źródłowe i metadane.
Potwierdź poprawny projekt i zapisaną scenę
Sprawdź pełną ścieżkę projektu w Unity Hub i edytorze. Zduplikowany projekt lub starsza kasa może zostać otwarta ze znaną nazwą i inną zawartością. Następnie sprawdź, która scena jest faktycznie załadowana. Nowa pusta scena nie jest dowodem na to, że zapisana scena produkcyjna zniknęła. Wyszukaj w zachowanym drzewie zasobów oczekiwany plik .unity i porównaj rozpoznawalne obiekty lub organizację scen.
Jeśli oczekiwana scena istnieje, otwórz kopię w toku prac nad projektem i sprawdź konsolę. Zapisz brakujące skrypty, nierozwiązane zasoby i błędy zależności przed wypróbowaniem poprawek. Pierwszy błąd może wyjaśnić wiele późniejszych objawów. Na przykład błąd kompilacji może uniemożliwić oczekiwane zachowanie, nawet jeśli źródło sceny i skryptu pozostanie obecne. Odzyskiwanie plików nie jest pierwszym rozwiązaniem problemu rozwiązywania zależności.
Odróżnij zasoby źródłowe od wygenerowanych danych
Unity generuje zaimportowane reprezentacje i pamięci podręczne na podstawie danych wejściowych projektu. Zachowana pamięć podręczna nie zastępuje w pełni brakujących plików źródłowych, oryginalnych metadanych ani zapisanych scen. Nie zakładaj, że zbudowana gra lub duży katalog Biblioteki zawiera łatwy do odzyskania, edytowalny projekt. Zachowaj te artefakty jako dowód, ale najpierw poszukaj prawdziwych źródeł projektu i istniejących kompletnych kopii.
Podobnie plik sceny niekoniecznie zawiera wszystkie tekstury, siatki, animacje i skrypty, do których się odwołuje. Jego użyteczność zależy od otaczającego projektu. Zrób inwentarz brakujących relacji, zamiast oceniać powrót do zdrowia po nazwie jednej odzyskanej sceny. Potrzebujesz spójnego zestawu zasobów źródłowych i identyfikatorów, a także konfiguracji projektu, która sprawi, że redaktor zinterpretuje te zasoby zgodnie z zamierzeniami.
Bezpłatna metoda 1: Przywróć pasujące zasoby i pliki meta
Metadane Unity rejestrują ważne informacje o importowanych zasobach, w tym ich tożsamość. Przywracając istniejące repozytorium lub kopię zapasową projektu, zachowaj każdy zasób wraz z oryginalnym plikiem .meta. Przywróć pasujący zestaw ze spójnej wersji do skopiowanego projektu. Unikaj mieszania starego zasobu z niepowiązanymi nowszymi metadanymi tylko dlatego, że ich nazwy bazowe są zgodne.
Jeśli metaplik zniknął, ale przetrwała znana, dobra kopia, porównaj go przed otwarciem projektu próbnego. Trzymaj Unity zamknięty, celowo zastępując skopiowane pliki projektu, aby nie importował niekompletnego stanu pośredniego. Następnie otwórz ponownie, korzystając z odpowiedniej wersji edytora i sprawdź odniesienia. Przywrócenie oryginalnej tożsamości może pomóc w rozwiązaniu istniejących odniesień, ale tylko wtedy, gdy pliki i kontekst projektu rzeczywiście odpowiadają sobie.
- Zidentyfikuj brakujący lub zastąpiony zasób i jego oczekiwaną ścieżkę projektu.
- Znajdź spójną istniejącą wersję zawierającą zarówno zasób, jak i jego oryginalny metaplik.
- Przywróć tę parę do zachowanego projektu próbnego, gdy edytor jest zamknięty.
- Otwórz ponownie projekt i sprawdź odpowiednie sceny, prefabrykaty i odniesienia do zasobów.
Nie twórz identyfikatorów jako skrótu
Ręczne przypisanie odgadniętego identyfikatora może spowodować kolizje lub skierować odniesienia do niewłaściwego zasobu. Znana nazwa pliku nie ustala oryginalnej tożsamości. Jeśli to możliwe, korzystaj z wiarygodnych istniejących metadanych i nie wprowadzaj zmian eksperymentalnych w stosunku do przyjętej wartości bazowej odzyskiwania. Jeżeli nie można ustalić oryginalnej tożsamości, należy udokumentować to ograniczenie i zamiast tego zaplanować celową naprawę referencyjną lub rekonstrukcję.
W przypadku utraty na poziomie folderu zachowaj metadane folderu oraz poszczególne zasoby towarzyszące. Przejrzyj pełną hierarchię i wszelkie relacje specyficzne dla projektu. Projekt może wykorzystywać pakiety, definicje zestawów, konfigurowalną konfigurację lub inne systemy, które dodają zależności poza widoczną sceną. Odzyskanie jednego zasobu może naprawić objaw, pozostawiając większą funkcję niekompletną, dlatego należy postępować zgodnie ze ścieżką, której dotyczy problem, przez cały projekt.
Dowolna metoda 2: Otwórz istniejącą zapisaną scenę w spójnej kopii
Przeszukaj istniejące kompletne kopie projektu i wersje repozytorium pod kątem ostatniej akceptowalnej zapisanej sceny. Zamiast resetować aktywny projekt, użyj osobnego koszyka lub skopiowanego folderu. Na początku zachowaj spójność wersji edytora. Znana zapisana scena może zapewnić stabilną linię bazową, ale może brakować w niej zmian wprowadzonych po zapisaniu. Porównaj to z zachowanymi zrzutami ekranu, notatkami i bieżącą zawartością projektu.
Po otwarciu sceny sprawdź jej hierarchię i ważne elementy. Przed założeniem usunięcia sprawdź, czy obiekty są nieaktywne, ukryte przez kontrolki edytora lub umieszczone poza bieżącym widokiem. Sprawdź, czy oczekiwana scena jest włączona w odpowiednim przebiegu projektu. Te kontrole mogą odzyskać dostęp do istniejącej pracy bez przywracania plików. Zapobiegają także nadpisaniu prawidłowej sceny podczas próby rozwiązania problemu z wyświetlaniem lub wyborem.
Porównaj obowiązki związane z prefabrykatami i scenami
Niektóre zmiany obiektów należą do zasobu prefabrykowanego, podczas gdy inne istnieją jako nadpisania specyficzne dla sceny. Odzyskanie starszego prefabrykatu może mieć wpływ na wiele scen, a przywrócenie sceny może nie przywrócić zmienionego prefabrykatu. Przed wybraniem kandydata określ, gdzie była przechowywana utracona wartość. Sprawdź instancję i jej zasób źródłowy w skopiowanym projekcie i zapisz relację, którą chcesz odzyskać.
Unikaj stosowania lub cofania każdego zastąpienia w ramach naprawy ogólnej. Może to zastąpić prawidłowe ustawienia specyficzne dla sceny. Celowo porównuj wartości komponentów, których to dotyczy, i obiekty podrzędne. Jeśli tylko w jednym przypadku wystąpi błąd, odbudowa prefabrykatów obejmująca cały projekt może okazać się przesadą. I odwrotnie, jeśli wiele scen ma ten sam uszkodzony prefabrykat, naprawianie pojedynczych instancji może ukryć wspólne źródło problemu, zamiast przywracać zamierzony zasób.
Bezpłatna metoda 3: Użyj istniejącego repozytorium lub eksportu źródłowego
Wcześniej zatwierdzona wersja projektu może łącznie dostarczyć sceny, skrypty, metadane i konfigurację. Sprawdź go w osobnej lokalizacji roboczej, łącznie ze wszystkimi obiektami o dużych plikach wymaganymi przez repozytorium. Mały plik wskaźnikowy nie jest rzeczywistą teksturą ani modelem. Zanim stwierdzisz, że zasób został odzyskany lub że niepowodzenie importu dowodzi uszkodzenia, sprawdź, czy w kasie znajduje się prawdziwa zawartość.
Jeśli nie zachowała się żadna natywna scena, istniejące eksporty źródłowe mogą wspierać częściową rekonstrukcję. Eksport modelu, zestaw tekstur lub klip animacji mogą pozostać cenne, ale nie odtwarzają wszystkich relacji między scenami, wartości komponentów ani historii edytora. Oznacz tę pracę jako rekonstrukcja. Trzymaj dowody źródłowe i nowe zmiany oddzielnie od autentycznie odzyskanych natywnych plików projektu, abyś mógł uczciwie ocenić pozostały wysiłek.
Zachowaj ostrożność w przypadku zależności pakietów i wtyczek
Stary projekt może nie załadować się poprawnie, jeśli brakuje wymaganych pakietów lub wtyczek. Przejrzyj zachowaną konfigurację pakietu i legalne źródła instalacji. Nie pobieraj losowych wtyczek zastępczych tylko dlatego, że błąd wspomina znajomą nazwę. Najpierw określ wersję i rolę oryginalnej zależności. Niezgodność wersji może zmienić serializację lub zachowanie, nawet jeśli wydaje się, że zasoby zostały pomyślnie zaimportowane.
Rozwiązywanie problemów z zależnościami należy oddzielić od przywracania zasobów. Zapisz, jakie zmiany w pakiecie wprowadziłeś i przetestuj je na kopiach. Jeśli odzyskany projekt oczekuje starszego edytora, otwarcie go bezpośrednio w nowszej wersji może spowodować migracje, które komplikują porównanie. Zachowaj niezmienioną linię bazową przed jakąkolwiek konwersją i zapisz uaktualnione wyniki osobno, dopóki nie sprawdzisz, czy ważna scena i zachowanie zasobu pozostają nienaruszone.
Poznaj ograniczenia odzyskiwania niezapisanych scen
Nie zakładaj, że Unity utrzymuje uniwersalną, trwałą historię automatycznego zapisywania każdej sceny i zasobu. Dostępne zachowanie odzyskiwania może zależeć od wersji, zainstalowanych narzędzi i tego, co trafiło na dysk przed incydentem. Jeśli edytor oferuje opcję odzyskiwania po awarii, zachowaj dostępne dane projektu i oceń oferowany wynik. Natychmiast zapisz przydatną odzyskaną scenę pod osobną nazwą.
Jeśli nie istnieje żadna kopia odzyskiwania, a scena nigdy nie została zapisana, zwykłe skanowanie usuniętych plików może nie pozwolić na znalezienie pełnego pliku sceny. Skoncentruj się na zachowanych zasobach źródłowych i rzeczywistym zarejestrowanym stanie projektu. Zrzut ekranu lub zbudowana aplikacja mogą pomóc w rekonstrukcji, ale żadna z nich nie zapewnia automatycznie oryginalnej edytowalnej sceny. Należy wyraźnie wskazać to ograniczenie, szacując, co udało się osiągnąć w ramach odzyskania pomocy.
Zachowaj tymczasowe dowody przed sprzątaniem
Po awarii unikaj narzędzi czyszczących i resetowania projektów, dopóki mogą pozostać przydatne dowody odzyskiwania. Zachowaj dostępny katalog projektu i odpowiednie dzienniki przed przystąpieniem do rozwiązywania problemów. Dzienniki mogą zidentyfikować scenę, wersję edytora lub uszkodzony zasób, nawet jeśli nie zawierają brakującej treści. Wykorzystaj je jako wskazówki przy wyborze ścieżki powrotu do zdrowia, a nie jako obietnicę, że samo miejsce zdarzenia przetrwa.
Jeśli skopiowany projekt otwiera się dopiero po usunięciu wygenerowanych danych, zachowaj oryginalną kopię bez zmian. Odbudowa zaimportowanych danych może rozwiązać problem pamięci podręcznej, ale nie może odtworzyć brakujących zasobów źródłowych ani ich oryginalnych identyfikatorów. Zrób to rozróżnienie w swoich notatkach. Pomyślny ponowny import dowodzi, że zachowane dane wejściowe mogą wygenerować użyteczne dane edytora; nie dowodzi, że obecne były wszystkie oryginalne dane wejściowe.
Sprawdź odniesienia poza widokiem pierwszej sceny
Scena może wyglądać poprawnie, podczas gdy ukryte zależności pozostają zepsute. Sprawdź ważne prefabrykaty, materiały, animacje, komponenty skryptów i odniesienia do interfejsu użytkownika. Sprawdź konsolę i przetestuj konkretną funkcję, która się nie powiodła. Jeśli projekt wykorzystuje sceny addytywne lub ładowanie środowiska wykonawczego, otwarcie jednej sceny jest tylko częścią walidacji. Podążaj normalnym punktem wejścia w kontrolowanym środowisku, aby odkryć brakujące zasoby wykorzystane później.
W przypadku zasobu przywróconego z metadanymi sprawdź odniesienia w więcej niż jednym miejscu, jeśli jest on powszechnie udostępniany. Upewnij się, że pojawia się zamierzona siatka lub tekstura, a nie jakikolwiek zasób tego samego typu. Kolizja referencji może spowodować powstanie wiarygodnej, ale błędnej treści. Używaj rozpoznawalnych szczegółów wizualnych, wartości komponentów i zachowań specyficznych dla projektu, aby zweryfikować tożsamość, zamiast polegać wyłącznie na braku komunikatów o błędach.
Sprawdź razem skrypty i serializowane wartości
Odzyskany skrypt może się skompilować, gdy wartości serializowanej sceny nie odpowiadają już jego polom. Przejrzyj pola o zmienionych nazwach, przypisania komponentów i ustawienia domyślne dotyczące zdarzenia. Jeśli skrypt został przeniesiony lub utworzony ponownie z innymi metadanymi, istniejące komponenty mogą nie połączyć się ponownie automatycznie. Porównaj oryginalny plik towarzyszący z oczekiwaną zależnością sceny przed wykonaniem ręcznych przypisań, które mogłyby ukryć podstawowy problem z tożsamością.
Następnie przetestuj przywrócone zachowanie za pomocą małego, powtarzalnego scenariusza. Na przykład sprawdź, czy odzyskana interakcja uruchamia się na zamierzonym obiekcie i używa poprawnie skonfigurowanej wartości. Koncentruj testy na celu odzyskiwania. W pomyślnej sesji ogólnego odtwarzania może zostać pominięta dokładnie funkcja, której dane zostały utracone, zwłaszcza gdy scena, której dotyczy problem, jest duża lub zawiera kilka alternatywnych ścieżek.
Przejrzyj konfigurację projektu i dane wejściowe kompilacji
Zachowaj informacje o wersji edytora projektu, manifesty pakietów i odpowiednie ustawienia w zaakceptowanym źródle. Scena przywrócona do dowolnego, świeżego projektu może zachowywać się inaczej ze względu na zmianę danych wejściowych, renderowania, warstw, fizyki lub konfiguracji kompilacji. Porównaj te ustawienia przed zmianą odzyskanej zawartości, aby to zrekompensować. W przeciwnym razie możesz wprowadzić nowe edycje sceny dla problemu należącego do środowiska.
W przypadku zespołów koordynuj zaakceptowaną wersję odzyskiwania w ramach istniejącego przepływu pracy projektu po przejrzeniu. Nie należy przypadkowo mieszać lokalnych metadanych eksperymentalnych ze udostępnioną wartością bazową. Sprawdź ostateczne zmiany w pliku i upewnij się, że zawierają rzeczywiste zasoby, a nie generowany szum. Przejrzysty punkt kontrolny odzyskiwania powinien wyjaśniać, które identyfikatory i zależności zostały przywrócone, jakie zachowanie zostało przetestowane i jaka rekonstrukcja pozostaje niekompletna.
Dowiedz się, kiedy odzyskiwanie pamięci masowej jest priorytetem
Jeśli na dysku projektu pojawiają się powtarzające się błędy odczytu, rozłącza się lub brakuje niepowiązanych folderów, potraktuj to jako problem z pamięcią, a nie z edytorem. Unikaj powtarzającego się importu i opierania się na tym wolumenie. Operacje te mogą zapisać istotne dane i pogorszyć niestabilną sytuację. Zachowaj czytelną zawartość i wybierz odpowiednią metodę odzyskiwania dla stanu urządzenia.
W przypadku zdrowego wolumenu, który został niedawno usunięty, rozsądne może być ukierunkowane skanowanie plików. Cel odzyskiwania powinien obejmować pliki źródłowe i pasujące metadane, a nie tylko to, co tworzy rozpoznawalny podgląd. W przypadku pamięci, która odrzuciła już usunięte bloki, odzyskiwanie może być ograniczone. Żadne ustawienia edytora ani interfejs odzyskiwania nie mogą zagwarantować, że nadpisane lub odrzucone dane źródłowe staną się ponownie dostępne.
Odzyskaj scenę z kilkoma generacjami tego samego zasobu
Projekt może zawierać kilka wersji modelu lub tekstury, które wyglądają niemal identycznie. Przed przywróceniem porównaj oryginalną ścieżkę, tożsamość metadanych i scenę, która się do niej odwołuje. Nowszy eksport o znanej nazwie może nie być aktywem, jakiego oczekuje scena. Zachowaj każdego kandydata i przetestuj go w skopiowanym projekcie. Pozwala to uniknąć zastąpienia prawidłowego odniesienia wizualnie wiarygodnym substytutem, który zmienia zachowanie w innym miejscu.
Sprawdź ustawienia importu, a także widoczne piksele lub geometrię. Skala, interpretacja tekstur, konfiguracja platformy i inne ustawienia mogą mieć wpływ na wynik niezależnie od wyglądu pliku źródłowego. Jeśli oryginalne metadane przetrwają, porównaj je z bieżącym stanem importu przed wprowadzeniem ręcznych zmian. Odzyskane źródło i jego zaakceptowane ustawienia powinny stanowić jeden celowy punkt odniesienia. Zachowaj nowe strojenie osobno, aby móc wyjaśnić, które części wyniku zostały przywrócone, a które skorygowane.
Sprawdź ścieżki ładowania środowiska wykonawczego
Niektóre zasoby pojawiają się tylko wtedy, gdy aplikacja uruchamia określoną funkcję. Podgląd sceny może zatem wyglądać na kompletny, gdy brakuje zawartości załadowanej w czasie wykonywania. Postępuj zgodnie z rzeczywistą ścieżką ładowania używaną w projekcie i przetestuj reprezentatywny przypadek. Nie twórz zduplikowanych zasobów tylko po to, aby wyciszyć symptom braku zasobu przed zrozumieniem oczekiwanego identyfikatora lub ścieżki. Rozwiązanie może ukryć pierwotną relację i utrudnić późniejsze odzyskanie.
Jeśli projekt korzysta z systemu zarządzania treścią lub wygenerowanego katalogu, zachowaj jego wiarygodną konfigurację i dane wejściowe. Regeneruj uzyskane dane dopiero wtedy, gdy zaakceptowane źródła będą spójne. Wygenerowany katalog wskazujący brakującą zawartość nie jest odzyskanym zestawem zasobów. Zapisz środowisko i zbuduj kroki używane do sprawdzania poprawności, aby inna osoba mogła odtworzyć test bez polegania na pozostałościach pamięci podręcznej z Twojego komputera.
Zachowaj odrębność zawartości pakietu i zawartości projektu
Brakujący zasób może należeć do zainstalowanego pakietu, a nie do własnego folderu Zasoby projektu. Zidentyfikuj własność przed przywróceniem plików do nowej lokalizacji. Kopiowanie zawartości pakietu do projektu może zmienić odniesienia i zaktualizować zachowanie w sposób, który komplikuje porównanie. Najpierw przywróć uzasadnioną oczekiwaną zależność i sprawdź, czy pierwotna relacja powróciła. Traktuj celową wymianę lokalną jako osobną zmianę mającą swój własny powód.
W przypadku niestandardowych pakietów obsługiwanych w projekcie uwzględnij ich źródło i konfigurację w spisie odzyskiwania. Kopia zapasowa projektu, która wyklucza ścieżkę pakietu lokalnego, może wyglądać na kompletną, ale brakuje w niej niezbędnego kodu lub zasobów. Przetestuj zaakceptowaną kopię z lokalizacji, która nie rozpoznaje przypadkowo starej ścieżki. Ujawnia to zależności, które zwykła stacja robocza mogłaby w przeciwnym razie udostępniać w trybie cichym.
Przejrzyj zaakceptowane odzyskanie jako zmianę zasobu zespołu
Zanim zwrócisz wynik do współdzielonego rozwoju, sprawdź wspólnie ostateczny zasób i zmiany w metadanych. Poszukaj nieoczekiwanych zmian identyfikatorów, zduplikowanych zasobów i wygenerowanych plików, które nie należą do normalnego repozytorium. Koncentruj się na punkcie kontrolnym odzyskiwania i opisz konkretną naprawioną scenę lub element. Pomaga to członkom zespołu przejrzeć zmiany w relacjach, zamiast stawić czoła dużym, niewyjaśnionym różnicom w imporcie.
Jeśli niektóre odniesienia wymagały ręcznej rekonstrukcji, wypisz je i przetestuj ich ważne zastosowania. Nie zakładaj, że naprawione odniesienie w jednej scenie obejmuje wszystkie ścieżki prefabrykowane lub wykonawcze. Zachowaj surowe odzyskane pliki do czasu, aż udostępniona linia bazowa przejdzie odpowiednie kontrole. Jasno zaakceptowany zestaw zasobów, niewielka notatka o odzyskaniu i zweryfikowana niezależna kopia zapewniają zespołowi niezawodne miejsce do kontynuowania pracy.
Kiedy oprogramowanie do odzyskiwania plików pasuje do sytuacji
PandaOffice Drecov może zapewnić ścieżkę wyszukiwania usuniętych plików scen, zasobów źródłowych lub metadanych w czytelnej pamięci. Nie naprawia automatycznie relacji GUID Unity ani nie rekonstruuje całego projektu z izolowanych plików. Użyj go po sprawdzeniu rzeczywistych lokalizacji projektu, zapisanych kopii i istniejącej kontroli wersji. Źródła rodzime z zachowanymi powiązaniami zwykle zapewniają jaśniejszy punkt wyjścia niż niepowiązani, odzyskani kandydaci.
Zanim zaczniesz skanować w poszukiwaniu nietypowych formatów projektów, potwierdź obsługę plików dostępną w zainstalowanej wersji. Zachowaj wiarygodne pliki, nawet jeśli brakuje im wizualnego podglądu, i porównaj je za pomocą skopiowanego projektu. Przechowuj odzyskane miejsce docelowe oddzielnie od woluminu, którego dotyczy problem. Ważnym pytaniem jest, czy odzyskany zestaw tworzy spójny, edytowalny projekt, a nie to, czy skan zawiera listę znanych rozszerzeń.
Krok 1: Wybierz wolumin zawierający brakujące dane projektu
Wybierz miejsce, w którym znajdował się rzeczywisty folder Zasoby, zapisana scena lub metadane. Jeśli zasoby źródłowe znajdowały się w innej powiązanej lokalizacji, zapisz ten oddzielny cel wyszukiwania. Unikaj tworzenia projektu zastępczego na woluminie, którego dotyczy problem. Zarezerwuj inne, zdrowe miejsce docelowe dla danych wyjściowych odzyskiwania i potwierdź tożsamość woluminu na podstawie jego pojemności i oryginalnej ścieżki projektu, zamiast zgadywać na podstawie samej litery dysku.
Krok 2: Porównaj zasoby, sceny i pliki towarzyszące
Przejrzyj dostępne ścieżki, nazwy, rozmiary, daty i obsługiwane podglądy. Zatrzymaj oryginalnych metatowarzyszy wraz z ich zasobami, gdy tylko przeżyją. Zachowaj wersje konkurencyjnych scen osobno, ponieważ najnowszy kandydat może odzwierciedlać niekompletny zapis. Po odzyskaniu sprawdź rozpoznawalną treść i strukturę projektu. Wizualnie poprawna tekstura nie oznacza, że przetrwała także jej pierwotna tożsamość lub wszystkie powiązane z nią odniesienia do scen.
Krok 3: Odzyskaj w innym miejscu i przetestuj pełną kopię
Zapisz wybrane pliki w osobnym miejscu docelowym, a następnie złóż projekt próbny z kopii. Użyj odpowiedniej wersji edytora, sprawdź błędy i przetestuj dotknięte sceny i prefabrykaty. Zachowaj odzyskane oryginały w niezmienionej formie podczas rozwiązywania zależności. Przed wymianą aktualnej roboczej linii bazowej potwierdź zarówno treść wizualną, jak i zachowanie projektu. Sukces kopiowania plików to dopiero początek odzyskiwania projektu Unity.
Potwierdź nadający się do edycji projekt
Dobry wynik końcowy obejmuje zaakceptowane sceny, zasoby źródłowe, oryginalne metadane, jeśli są dostępne, oraz konfigurację wymaganą do ich otwarcia. Zapisz wszystkie odniesienia, które naprawiłeś ręcznie, i całą zrekonstruowaną zawartość. Dzięki temu wynik można sprawdzić i zapobiec przyszłym nieporozumieniom co do tego, które części pochodzą z autentycznie zapisanego stanu. Zachowaj zweryfikowany projekt w innej lokalizacji przed wznowieniem normalnej pracy produkcyjnej.
- Potwierdź poprawną ścieżkę projektu, wersję edytora i kompletne foldery źródłowe.
- Sprawdź brakujące skrypty, tożsamość zasobów, powiązania prefabrykatów i ważne odniesienia do scen.
- Uruchom skoncentrowane kontrole trybu gry lub projektu dla funkcji, której dotyczy problem.
- Zapisz spójny punkt kontrolny odzyskiwania i przetestuj niezależną kopię tego punktu kontrolnego.
Chroń relacje zasobów w przyszłych kopiach zapasowych
Przechowuj zasoby i ich metapliki razem w ramach normalnego przepływu pracy związanego z kontrolą wersji i tworzeniem kopii zapasowych projektu. Uwzględnij konfigurację pakietu i ustawienia projektu oraz sprawdź, czy zawartość dużych plików faktycznie dotarła do kopii zapasowej. Unikaj przenoszenia lub zastępowania plików projektu poza edytorem bez zrozumienia konsekwencji metadanych. Zbiór tekstur i modeli jest przydatny, ale projekt Unity, który można odzyskać, wymaga również ich tożsamości i relacji.
Na koniec przetestuj przywracanie małej, kompletnej kopii projektu. Otwórz zapisaną scenę, sprawdź prefabrykat i przeprowadź jedną reprezentatywną interakcję. Ujawnia to brakujące pliki źródłowe lub założenia pakietu przed prawdziwym incydentem. Pomyślny test kopii zapasowej daje dowód, że projekt można nadal edytować, a nie tylko pokazuje, że folder o właściwej nazwie istnieje na innym urządzeniu.
Powiązane zasoby odzyskiwania
Zapoznaj się z odpowiednimi opcjami odzyskiwania: Odzyskiwanie dysku twardego, Odzyskiwanie zewnętrznego dysku twardego.
Aby zapoznać się z innym przypadkiem odzyskiwania środków i jego praktycznymi kontrolami, przeczytaj powiązany przewodnik odzyskiwania.
Sprawdź wskazówki dostawcy dotyczące zainstalowanej wersji: oficjalna dokumentacja odzyskiwania 1, oficjalna dokumentacja odzyskiwania 2, oficjalna dokumentacja odzyskiwania 3.
