Lista bugów.

[DavivaD]

Ponieważ nie posiadam konta na Githubie i angielski nie jest moją dobrą stroną wypisze tutaj wszyskie bugi które odkryłem w CG.
Legenda
Zielony Napis - Bug naprawiony.
Czerwony napis - Bug nienaprawiony.


Lista:

• Gra losowo krzaczy podczas strzelania broniacych bazy dział organicznych w misji z AfC:R.1.
  
• Technik z Houston nie moze kozystać z komendy 'build();' chociaz ma w ekwipunku dzialo neutronowe.
  
• Każdy zaprogramowany objekt ma problem z goto w statku kosmicznym.
  
• Dynamiczne cienie bugują sie na PowerCaptor.
  
• RepairCenter próbuje naprawić coś co wgl nie ma na jego platformie.
  
• Wyprodukowane AlienAnt nie mają programu z misji 9.4.
  
• AlienWasp może zniszczyć Shielder pomimo włączonej tarczy.
  
• Podczas budowania Me może się poruszać.
  
• Random Crash podczas przełączania stron na SatCom.
  
• Podczas podnaszania można się poruszać.
  
• W misji 8.2 Odgromnik nie ładuje Baterie Robota (w tym przypadku latające działo organiczne).
  
• Efekt 'pyro=LOST' nie działa na botach. (nietestowane na innych).
  
• Na silniku gl33 Obiekt który zasłania nasz obecnie wybrany obiekt ma jaśniejszą przeźroczystość niż na zwykłym silniku (nietestowane na gl21).
  

[Simbax]

nie posiadam konta w Githubie

To je załóż. Jestem złośliwy? A oto, jak można odebrać twoją wypowiedź: "bugi się zgłasza na GitHubie, ale jestem zbyt leniwy by założyć konto". Być może go nie założyłeś, bo nie umiesz pisać po angielsku, w takim wypadku należało to napisać. Inaczej, jak widzisz, niektórzy mogą cię uznać za kogoś utrudniającego pracę i robiącego bałagan, bo teraz trzeba sprawdzić, czy te twoje bugi nie zostały już zgłoszone i ktoś może zmarnuje czas przepisując je na GitHuba, a ponadto informacja i ewentualna dyskusja o bugu będzie w dwóch różnych miejscach. Nie wymagam znania języka, bo jego nauka trwa latami, ale założenie konta to kilka minut. Podsumowując: dlaczego nie założyłeś konta?

A, i możesz nie posiadać konta co najwyżej na GitHubie, a nie "w".

[tomaszkax86]

Uważam, że niepotwierdzone issues/nowe funkcje powinny być omówione przed ich dodaniem. Forum jest dobrym miejscem ta takie dyskusje. Zresztą lepiej, jeśli dodawaniem issues zajmą się osoby znające angielski na odpowiednim poziomie. Preferowałbym jednak, aby na forum nie oznaczać tekstu kolorami. Wystarczyłby sam tekst, ewentualnie jakieś oznaczenie, np. [Rozwiązany] dla problemów rozwiązanych.

10 strzelających dział organicznych tworzy dużą liczbę cząsteczek. Wątpię, aby problemem była grafika, raczej jest to przepełnienie bufora lub niemożność alokacji pamięci. Trzeba by sprawdzić implementację cząsteczek. Najlepiej gdybyś mógł dostarczyć nam logów. Sprawdź może, ile pamięci zużywają cząsteczki podczas strzelania z odrobinę mniejszej liczby dział, tak aby nie doszło do błędu.

To, że technik z Houston nie może budować, nie jest samo w sobie błędem. Nie jest to jednostka, którą można normalnie kontrolować i tworzyć podczas gry, więc tego nie potrzebowała. Możemy natomiast to dodać, tylko podaj jakieś sensowne argumenty.

[krzys_h]

https://github.com/colobot/colobot/blob/...icle.h#L41
limit jest 500 cząsteczek

I teoretycznie nie powinno dojść do przepełnienia, przynajmniej przy dodawaniu nowych:
https://github.com/colobot/colobot/blob/...e.cpp#L331

[tomangelo]

W moim przypadku nic nie wywalało, przynajmniej nie na najnowszej wersji dev na Linuxie. Sprawdzę to jeszcze na Windowsowych dev i Release.

edit: Na Windowsowym dev buildzie faktycznie wywaliło grę. Poniżej logi z gdb:

Spoiler :

Code:

Program received signal SIGSEGV, Segmentation fault.

0x00467424 in CObject::GetPosition (this=0x0, part=0)
    at /home/colobot-compilebot/repo/main/src/object/object.cpp:1601
(gdb) 1601      /home/colobot-compilebot/repo/main/src/object/object.cpp: No such file or directory.

backtrace

#0  0x00467424 in CObject::GetPosition (this=0x0, part=0)
    at /home/colobot-compilebot/repo/main/src/object/object.cpp:1601
#1  0x0051daac in Gfx::CPyro::EventProcess (this=0x105fb170, event=...)
    at /home/colobot-compilebot/repo/main/src/graphics/engine/pyro.cpp:1133
#2  0x0043e7b3 in CRobotMain::EventFrame (this=0x60573b0, event=...)
    at /home/colobot-compilebot/repo/main/src/object/robotmain.cpp:2664
#3  0x00438928 in CRobotMain::ProcessEvent (this=0x60573b0, event=...)
    at /home/colobot-compilebot/repo/main/src/object/robotmain.cpp:687
#4  0x00434d51 in CController::ProcessEvent (this=0x82e2388, event=...)
    at /home/colobot-compilebot/repo/main/src/app/controller.cpp:87
#5  0x0040ad7a in CApplication::Run (this=0x3d865e8)
    at /home/colobot-compilebot/repo/main/src/app/app.cpp:988
#6  0x00401755 in SDL_main (argc=argc@entry=3, argv=argv@entry=0x3d85298)
    at /home/colobot-compilebot/repo/main/src/app/main.cpp:146
#7  0x0060c01e in console_main (argc=argc@entry=3, argv=argv@entry=0x3d85298)
    at ./src/main/win32/SDL_win32_main.c:315
#8  0x0060c0d8 in WinMain@16 (hInst=0x400000, hPrev=0x0,
    szCmdLine=0x3c24811 "-datadir ./afc", sw=10)
    at ./src/main/win32/SDL_win32_main.c:398
#9  0x0090401b in main ()
(gdb)

Dzieje się to po zniszczeniu kilku botów.

edit2: Nie pojawia się to za każdym razem, chociaż jest pewna reguła. Gdy przylatują 2 boty i zniszczymy je od razu, wszystko idzie dobrze. Gdy ten pierwszy zostanie zniszczony od tego drugiego bota (a drugiego i kolejne zniszczymy manualnie), wtedy po którymś razie (jeszcze nie rozpracowałem reguły) następuje crash i podany wyżej log.

[tomaszkax86]

Zdaje się, że problem znajduje się tutaj:

https://github.com/colobot/colobot/blob/....cpp#L1133

m_object może być NULL, ale nie jest to sprawdzane w tym kodzie. Zapewne obiekt przypisany do cząsteczki został zniszczony a ta próbowała sprawdzić jego pozycję. Możliwe, że to nie zachodzi w większości przypadków, stąd też mamy losowe crashe. Dodanie warunku sprawdzającego m_object != nullptr powinno to naprawić. W ogóle widzę, że implementacja cząsteczek też do przepisania w przyszłości. Spaghetti jak wszędzie indziej.

[DavivaD]

To, że technik z Houston nie może budować, nie jest samo w sobie błędem. Nie jest to jednostka, którą można normalnie kontrolować i tworzyć podczas gry, więc tego nie potrzebowała. Możemy natomiast to dodać, tylko podaj jakieś sensowne argumenty.

Większa wolność podczas tworzenia własnej misji z kluczowym obiektem którym jest 'tech'.
Bez builda dla technika mi uniemożliwia napisanie kilku misji do AfC:R.
Szczególnie kiedy technik ma nam pomóc w budowaniu bazy.

[krzys_h]

To, że technik z Houston nie może budować, nie jest samo w sobie błędem. Nie jest to jednostka, którą można normalnie kontrolować i tworzyć podczas gry, więc tego nie potrzebowała. Możemy natomiast to dodać, tylko podaj jakieś sensowne argumenty.

Większa wolność podczas tworzenia własnej misji z kluczowym obiektem którym jest 'tech'.
Bez builda dla technika mi uniemożliwia napisanie kilku misji do AfC:R.
Szczególnie kiedy technik ma nam pomóc w budowaniu bazy.

Kiedyś istniało coś takiego:

Code:

CreateObject ignoreBuildCheck=true

Pozwala to wyłączyć sprawdzanie EnableBuild/DoneResearch dla danego obiektu. Nie pamiętam tylko, czy wyłącza to też sprawdzanie typu obiektu.
PS. Me też nie może używać build();

---

EDIT 2015-04-18 11:30:
Problem z crashem w cząsteczkach powinien być już naprawiony, czekam na potwierdzenie

---

EDIT 2015-04-18 11:42:
Tech też już może budować

[RaptorParkowsky]

Przetestowałem ostatnie zmiany i jakoś zgrabnie to wszystko działa. Najwyżej Tech się dziwnie zachowuje, co później będzie warto poprawić. Chodzi o to, że przy zastosowaniu goto(zmienna.position); Techowie lub astronauci zwykle lecą do miejsca docelowego, nawet jeśli nie mają jet packa oraz w samej misji nie jest aktywne latanie. Warto również w przyszłości deaktywować możliwość programowego budowania Me i Tech, gdy ci nie mają zestawu przetrwania.

Zrobiłem próbę z działami organicznymi (Windows, dev~r87ccb75, na moim PC) , i nie udało się gry scrashować. Być może błędy z cząsteczkami mogą występować w sprzętach takich jak mój laptop, gdzie przecież w jednym ćwiczeniu z pająkami zasięg działa nie sięgał 40 colometrów. Tak czy siak, zalecam jeszcze innym to sprawdzić.

Jeśli nikt nie będzie miał jeszcze nic do powiedzenia w związku z tym tematem, to myślę, że będę mógł jutro ten temat zamknąć i zarchiwizować. Zalecam bugi zgłaszać na GitHubie, zaś propozycje zmian mogą być w osobnych tematach na forum, tak angielskim jak i polskim.

[tomangelo]

Odpaliłem misję kilka razy, robiłem wszystko identycznie jak przed tą poprawką, ale nic nie wywaliło. Wygląda na to, że jest to już naprawione. Czekamy jeszcze na potwierdzenie od @DavidaD i sądzę że można już przygotowywać się do wydania stabilnej wersji 0.1.5 i rozpoczęcia prac nad 0.1.6.
Ten temat można chyba zamknąć, a w przyszłości (jeśli ktoś nie zna angielskiego dość dobrze) zakładać pojedyncze tematy typu "zauważyłem bug tu i tu".

[DavivaD]

Rzeczywiście... teraz nie crashuje gry.

---

Kolejny bug...

Każdy zaprogramowany objekt ma problem z goto w statku kosmicznym.
demo - http://youtu.be/G90J9MKVGSc

[krzys_h]

goto zawsze miało problemy z poruszaniem się na statku. Na chwilę obecną nic z tym nie zrobimy, chyba że ktoś przepisze cały algorytm goto() (jakieś 2200 linijek kodu)

[DavivaD]

Zauważyłem że dynamiczne cienie się bugują na PowerCaptor.
NP: Te spicaste coś przenika przez 'polkole' anteny PowerCaptor i jego cien widac gdzie niepowinnien byc.

[tomaszkax86]

Gdybyś mógł pokazać screenshota, to byłoby fajnie.

[DavivaD]

---

Kolejny BUG:Zaprogramowany przez Scenę robot po zmianie jego programu (np. Notepad++) to program w grze nie resetuje...

[tomaszkax86]

Jest to problem spowodowany "nieskończenie cienką" geometrią talerza. Nie mogę nic na to poradzić, jedyne rozwiązanie to zmiana geometrii modelu na "grubą".

Wyjaśnij dokładnie dlaczego program miałby się resetować i w jakiej sytuacji?

[tomangelo]

Kolejny BUG:Zaprogramowany przez Scenę robot po zmianie jego programu (np. Notepad++) to program w grze nie resetuje...

Edytując plik w zewnętrznym programie zmieniasz tylko oryginalny plik na dysku twardym, natomiast orginalna zawartość wciąż "siedzi" w pamięci gry.

[DavivaD]

Ugh... Wysle filmik z tym Bugiem.

FILMIK:
https://www.youtube.com/watch?v=l4YGNXoa...e=youtu.be

---

EDIT: Filmik został juz wyslany.

[tomaszkax86]

Ten "bug" to taki ficzer, który masz w normalnych misjach. Gdy powtarzasz misję to każdy istniejący domyślnie robot ma zapisane programy, które im wcześniej napisałeś. To samo jest w swobodnej grze. Z tym, że w swobodnej grze zwykle nie masz istniejących robotów i zwykle użytkownik nie edytuje tak map jak ty to zrobiłeś. Jeśli chcesz zresetować programy, powinieneś usunąć je z katalogu saves/gracz/. Ich nazwy to klucz do pliku mapy, dla swobodnej gry to chyba "fxxxyyyzzz.txt", gdzie xxx, yyy i zzz to odpowiednio numery planety, mapy i obiektu.

[DavivaD]

Srsly? A ja myslalem ze to bug... Noto zdejmuję z listy bugów.