To taka "praktyka programistyczna". Pomijając to czy dobra, czy zła, czy jeszcze jakaś inna- chodzi o to, że procedura zapisu modelu wygląda w KSP (najwyraźniej) jakoś tak:
- sprawdź, czy już istnieje plik o nazwie X (nazwa pliku to nazwa modelu)
- jeżeli nie- utwórz (jeżeli tak- zadaj pytanie, czy user jest pewien, że chce nadpisać stary model, lub nie pytaj, jeżeli właśnie do edytuje)
- wygeneruj zawartość pliku (plik jest w postaci innej, niż ta na której gra pracuje... najpewniej... dlatego trzeba "przekonwertować" do formy znanej z pliku)
- zapisz wygenerowaną zawartość do pliku o nazwie X
Jeżeli podczas generowania zawartości pliku (który utworzony został na wstępie) coś padnie- zostaje nam pusty plik
//To tylko luźne dywagacje, jedna z możliwych ścieżek do uzyskania takiego błędu. Nawet jeżeli jest w istocie tak jak napisałem, to cały proces jest o wiele bardziej złożony, a więc i najpewniej dający więcej możliwych dróg do uzyskania pustego pliku, nie mówiąc o innych rzeczach
No, jeszcze jednym komentarzem rzucę. Tak już bardziej ogólnie
Często stosuje się, przynajmniej w przypadku Linuksa, puste pliki w charakterze "flag". Windows pewnie też się do tej mody stosuje, bo to wygodne. Generalnie rzecz biorąc- każdy program możesz uruchomić wiele razy. Taki notatnik chociażby. Odpalmy więc dwa razy notatnik. Możesz niezłego bajzlu narobić edytując ten sam plik dwoma programami, prawda? By programy wiedziały o sobie- można zapisać obok edytowanego pliku jakiś drobny, choćby pusty plik. Edytując dsa.txt notatnik utworzy pusty plik dsa.txt.block co będzie zwykłą "flagą" dla pliku dsa.txt która powstrzyma każdy inny notatnik (poza tym który tę flagę utworzył) przed edycją pliku dsa.txt. Przyjemne, przyjazne, proste i dość skuteczne. Także- plik pusty samym swoim faktem istnienia już niesie jakąś treść. Tak tomistycznie trochę...
Opowiadaj jakie rezultaty, ciekaw jestem do czego doszedłeś. Coś mi mówi, że jest wspólny mianownik dla naszych problemów (w moim przypadku- minionych, choć przyczyna domniemana jedynie).