Eksperyment z łatką binarną

[Ra]

Korzystając z okazji chciałbym przeprowadzić eksperyment ze stosowaniem łatek binarnych. Do jego zastosowania niezbędny jest malutki programik bspatch.exe. Program jest do pobrania ze strony autora:
http://sites.inka.de/tesla/others.html#bsdiff
albo z bezpośredniego linku (wersja pod Windows – 73kB):
http://sites.inka.de/tesla/download/bsdiff4.3-win32.zip

W załączniku znajduje się spakowany pliczek EU07_424.exe.bsdiff. Należy go wypakować wraz z wyżej wymienionym archiwum do głównego folderu MaSzyny, a następnie z linii poleceń wykonać:

Kod: [Zaznacz]

bspatch EU07_424.exe EU07_424a.exe EU07_424.exe.bsdiffNałożenie tej łatki powinno naprawić otwieranie drzwi w EZT, jeśli do uruchomienia scenerii użyje się zmodyfikowanego pliku. Jeśli eksperyment się powiedzie, to będzie można taką funkcjonalność wbudować w Rainsted i udostępniać np. poprawki modeli czy tekstur w formie bardzo krótkich łatek. Jednym z problemów do rozpoznania jest nałożenie łatki na nieodpowiednią wersję pliku. Już teraz widzę, że możliwe jest podanie tej samej nazwy jako plik pierwotny i wynikowy, a wielokrotne nałożenie łatki daje w takim przypadku za kolejnym razem inną zawartość pliku wynikowego. Bezpieczniej by było, gdyby w łatce zapisane były np. CRC32 pliku sprzed i po modyfikacji, a program by zgłaszał błąd w przypadku niezgodności.

[muri]

Mi się wydaje, ze więcej by z tym było zabawy niż korzyści. Jedyne co zyskujemy, to mniej danych do przesłania - bo w przypadku poprawki do EXE nie trzeba ściągać całej nowej wersji a tylko plik różnicowy. Chyba że są jakieś inne korzyści, ale ja takich nie widzę.

[Ra]

Akurat w przypadku EXE korzyść z wielkości jest niewielka. Myślałem raczej o plikach DDS czy E3D na większą skalę. Np. był błąd w generowaniu E3D, który spowodował umieszczenie wszystkich submodeli w fazie nieprzezroczystych, co się przekłada na znikanie pojazdów oglądanych przez szyby. Należało by teraz wygenerować wszystkie E3D bez tego błędu, co da dosyć dużą paczkę do pobrania, którą nie wszyscy pobiorą. A w praktyce to będzie zmienione tylko kilkanaście bitów na plik i paczka z poprawkami może być na tyle mała, że dołączenie jej do nowej wersji Rainsted będzie niezauważalne. Podobnie w przypadku DDS, ktoś może dojść do wniosku, że na kilkudziesięciu teksturach warto by poprawić kilka pikseli odpowiadających np. za czerwone światła.