Bug Reports

Verdict:

Verdict:

Verdict:

Verdict: CZESCIOWO. Wiekszosc nagrod OK (serwer konwertuje serverid->clientid). ALE bloody edge (3856) i dreaded cleaver (3859) maja zly sprite. Nasz items.otb: 3856->clientid 13481, 3859->13482; zrodla 8.6/7.6 mowia 2591/2594. ALE weryfikacja renderem (render-clientid.php): clientid 2591 TEZ nie pokazuje miecza bloody edge (blady kosciany ksztalt) - czyli prosta podmiana clientid NIE naprawi. To problem nieprzemapowanego sprite'a (jak #68): wlasciwa grafika siedzi pod innym clientid albo nie zostala scalona do Tibia.dat. Wymaga dedykowanej roboty na sprite'ach, nie szybkiej podmiany w items.otb. Status zostaje potwierdzony (reszta nagrod dziala).

Verdict: POTWIERDZONY. Drzwi 5896 (closed door) na 32819,31958,8 to drzwi-sierota bez dzialajacej pary "otwarte": atrybut transformUseTo jest PUSTY (value=""), a id jest podpiete pod other/doors.lua (actions.xml linia 679). doors.lua dla zwyklych drzwi bez transformUseTo dochodzi do return false -> uzycie nic nie robi. To NIE zamek: brak w tablicy DOORS, brak "It is locked.", brak actionid na kafelku. Luka po naprawie martwych drzwi z 2026-08-12 (tamten skan szukal BRAKU atrybutu, a te maja atrybut pusty). Ten sam defekt ma 34 rodzaje drzwi, 25 wystepuje na mapie = 691 sztuk. Naprawa: przeniesc sieroty z doors.lua na drzwi-przejscie.lua (jak 374 inne), ewentualnie nadac poprawne transformUseTo (wymaga analizy orientacji z ukladu mapy). Czeka na decyzje i wgranie.

Verdict: Potwierdzone co do faktu. Okno hotkeyow ma cztery pozycje z pozniejszych wersji Tibii: "Use on yourself", "Use on target", "With crosshair" i "Use at cursor position" - modules/game_hotkeys/hotkeys.otui, wiersze 146-180. WAZNE ROZROZNIENIE: sam protokol 7.72 uzycie przedmiotu z celem ZNA - serwer obsluguje pakiet 0x83 (parseUseItemEx, protocolgame.cpp:1171). To nie jest wiec funkcja martwa, tylko element okna, ktorego oryginalny klient 7.6 nie mial. Usuniecie jest kwestia zgodnosci z epoka, a nie poprawnosci dzialania. NAPRAWA: wyciac te cztery pozycje z .otui ORAZ z hotkeys_manager.lua, ktory sie do nich odwoluje - getChildById("useOnSelf"/"useOnTarget"/"useWith"), useRadioGroup oraz obsluga HOTKEY_MANAGER_USEONSELF i USEONTARGET. Samo usuniecie z okna zostawiloby odwolania do nieistniejacych elementow i wysypalo caly modul hotkeyow. Czeka na zgode: to zmiana w kliencie rozdawanym wszystkim graczom.

Verdict: NAPRAWIONE (czeka na Twoj test + restart). 8 sklepowych NPC Rookgaard (Al Dee, Lily, Loui, Norma, Obi, Seymour, Tom, Willie) przeniesionych na plac przy depo Thais (32367-32371 x 32232-32236, z7, bialy marmur, pola zweryfikowane jako wolne i przechodnie). Cipfried (mnich) zostal na Rookgaard. Rabbit z bloku Loui ocalal. map-spawn.xml wczytuje sie przy starcie - wejdzie po RESTARCIE serwera.

Verdict: Potwierdzone. Sklep ma jedna oferte na wszystkie stroje: config.php pozycja 11, Outfit with both addons, 30 punktow za dowolny z 23 strojow z listy. Citizen kosztuje tyle samo co Warmaster, Yalaharian czy Nightmare. Wlasna cene ma tylko Golden Knight (pozycja 12, 150 punktow), bo to stroj wylacznie sklepowy. Zmiana jest prosta, bo cena idzie w calosci z jednego pola: buy[points]. Wystarczy dopisac cene do kazdego wpisu w tablicy wybor, a w shop.php zaraz po sprawdzeniu wariantu (linia 38) nadpisac buy[points] wartoscia z wybranego wpisu. Reszta, czyli odjecie punktow, wpis do logu i komunikat o braku punktow, czyta juz to samo pole i nie wymaga zmian. Zeby cena byla widoczna przy kazdej pozycji listy, trzeba jeszcze tknac linie 342. Moge zaproponowac widelki cenowe na podstawie audytu zrodel addonow, ktory mam gotowy. Plikow strony nie zmieniam bez Twojej zgody.

Verdict: Potwierdzone, i powazniej niz propozycja: trafienia krytyczne JUZ SA w silniku, tylko nie robia nic. config.lua ma criticalHitChance = 7, criticalHitMultiplier = 1, displayCriticalHitNotify = false. Sedno w weapons.cpp:374 - maxDamage = pow(maxDamage, mnoznik). Przy mnozniku 1 to pow(x,1) = x, czyli krytyk wypada co czternasty cios i zadaje DOKLADNIE zwykle obrazenia, a napis CRITICAL jest wylaczony. Nikt tego nie widzi i nic z tego nie ma. Domyslna wartosc silnika tez wynosi 1, wiec nic nie zostalo zepsute - to nigdy nie bylo wlaczone. To POTEGOWANIE, nie mnozenie, wiec premiuje mocne ciosy: przy 1.05 obrazenia 100 rosna do 126, a 1000 do 1413; przy 1.10 odpowiednio do 158 i 1995. Proponuje 1.05 i wlaczenie napisu. Druga czesc zgloszenia, najmocniejszy cios w statystykach, nie istnieje wcale i wymaga dopisania: magazyn gracza plus strona. To osobna robota. config.lua nie ruszam bez Twojej zgody.

Verdict: NAPRAWIONE (czeka na Twoj test + restart). Oba portale (1387) na 32089,32171,9 i 32082,32171,9 mialy cel 0,0,0 (martwe) - lacza dwa pokoje przez skalna bariere x32084-32086. Dodane do NOWEJ recznej listy data/lib/066-teleporty-reczne.lua (report-driven, generator jej nie nadpisuje). 32089->32081, 32082->32090 - kazdy wyrzuca ZA drugi portal w kierunku marszu, bez petli odbijania. Pola ladowania zweryfikowane jako przechodnie. Wchodzi po RESTARCIE (onStartup).

Verdict: Potwierdzone. Na kafelku 32353,32086,7 leza DWA kamienie jeden na drugim: 1301 i 1300 (oba z zakresu 1296-1352 "stone"). Sprawdzilem to pytajac serwer o zawartosc kafelka, wiec to nie jest domysl z pliku mapy. W mapie 8.6 ten sam kafelek ma WYLACZNIE grunt, bez zadnego kamienia. Grunt zgadza sie co do grafiki (u nas 4526, w 8.6 9043, oba rysuja 4515), wiec rozni sie tylko to, co na nim lezy - dwa kamienie, ktorych oryginal nie ma. Naprawa do uzgodnienia: zdjecie obu kamieni z mapy albo pozostawienie jednego, jesli maja tam byc celowo. Nie ruszam mapy bez Twojej zgody. Przy okazji poprawilem wlasne narzedzie: items.xml zapisuje zakresy takze jako id="1296-1352", czego moj czytnik nie rozumial i pokazywal takie przedmioty jako bezimienne. Po poprawce nazwanych numerow jest 10409.

Verdict: To samo co w zgloszeniu 77 i ten sam wynik. Pozycja 32361,32086,7 ma - wg SERWERA, nie pliku mapy - grunt 4529 i przedmiot 4616, oba "grass", grafiki 4518 i 4605. Mapa 8.6 na tym samym kafelku ma dokladnie te grafiki. Przeszukalem tez okolice w promieniu 10 kratek: nie ma tam ani jednego kafelka shallow water (serwerowe 4608-4613 i 4620-4625). Numer 4610 ze zgloszenia to numer kliencki i odpowiada serwerowemu 4621 "shallow water" - sam numer jest wiec sensowny, tylko nie ma go na tej pozycji. Nie znajduje tu roznicy wobec oryginalu. Jesli widzisz wode na wlasne oczy, potrzebuje zrzutu ekranu - wtedy szukam dalej.

Verdict: Nie znalazlem usterki, ale opisze dokladnie, co sprawdzilem, bo numer w zgloszeniu myli. "ItemID: [4610]" to numer KLIENCKI - serwerowo odpowiada mu 4621, ktory faktycznie nazywa sie "shallow water" (zakres 4620-4625 w items.xml). Numer sie wiec zgadza. Problem w tym, ze na podanej pozycji 32369,32149,7 tej wody nie ma. Zapytalem SERWER, nie plik mapy: kafelek ma grunt 4529 i przedmiot 4616, oba nazwane "grass", o grafikach 4518 i 4605. W mapie 8.6 ten sam kafelek ma grafiki 4518 i 4605 - identyczne. Najblizsza prawdziwa shallow water lezy 9-10 kratek dalej, na 32378 i 32379 (y 32139), i tez jest identyczna z 8.6 co do numeru, grafiki i blokady. Czyli ani na tej pozycji, ani w poblizu nic nie rozni sie od oryginalu. Podejrzewam, ze linia z look pochodzi z innego kafelka niz ten, ktory opisujesz. Jesli nadal widzisz tam cos dziwnego - wrzuc zrzut ekranu, otworze zgloszenie ponownie.

Verdict: ZROBIONE I NA PRODUKCJI (restart 14:21). Loot WSZYSTKICH 108 bossow idzie teraz POMARANCZOWYM komunikatem (MESSAGE_STATUS_CONSOLE_ORANGE), nie zielonym. Mechanizm: flag lootmessage=0 w monster.xml wylacza silnikowy zielony komunikat, a creaturescript boss-loot-kolor.lua (onDeath) wypisuje loot na pomaranczowo do zabojcy. Czyta zwloki z opoznieniem 300ms (bo onDeath odpala sie przed dropLoot). Test: ubij bossa (np. /m Ushuriel albo /m Necropharus) -> komunikat 'Loot of ...' bedzie pomaranczowy.

Verdict: Potwierdzone i jest to moj blad z dzisiejszej kampanii przemapowania grafik. sandstone floor (777) dostal numer grafiki 13348, a ten wpis w Tibia.dat ma 2x2 kratki, 64 klatki i atrybut NIEPRZECHODNY - stad zarowno wyglad wody, jak i to, ze nie da sie tamtedy przejsc. Poprawny numer to 923; potwierdza go items.otb mapy 8.6, ktory dla tego samego przedmiotu serwerowego podaje wlasnie 923. Problem nie byl jednostkowy: 98 przedmiotow bedacych podloga dostalo grafike sciany, razem 46 470 kafelkow, a samo 777 odpowiadalo za 16 777 z nich. Grafiki cofnalem do numerow sprzed kampanii i zrestartowalem serwer 2026-09-09 - liczba kafelkow z rozjazdem klient/serwer spadla z 39 502 do 1 758. Reszta to starszy osad (4636, 4637, 4639 oraz grass 4616-4618), ktorego nie da sie przemapowac w miejscu, bo stary numer zawiera bajt sterujacy - wymaga przepisania calego items.otb. Prosze o sprawdzenie w grze.

Verdict: Odrzucone, bo to nie usterka tylko potwierdzenie, ze te drzwi maja zostac - i zostaja. Dla porzadku zapisuje ustalenia: drzwi uid 2127 (id 1221) na 32824,32231,12 rowniez nie ma w pliku mapy, stawia je skrypt startowy lib/063-questy-uid.lua (linia 14), tak samo jak trzy drzwi ze zgloszenia 73. Odnotowane przy tamtym zgloszeniu, zeby przy usuwaniu tamtych trzech nie usunac o jedne za duzo. Takie zgloszenia sa przydatne - bez tego wpisu wszystkie cztery wygladalyby na jedna grupe do skasowania.

Verdict: JUZ NAPRAWIONE (zgloszenie z 2026-09-09, fix 2026-09-10). Te 3 drzwi POI (uid 2117/2119/2121) NIE sa w mapie - pojawialy sie tylko ze skryptu osadzajacego uniqueid (data/lib/063-questy-uid.lua). Dzien po zgloszeniu swiadomie je wykluczylem z osadzania - z dokladnie tego powodu co podales: 'PoI: przejscie jest teleportem, drzwi zbedne'. Skan regionu POI na mapie = 0 drzwi 1219. Zywy serwer ma wersje z wykluczeniem. Zostaly tylko martwe (nieszkodliwe) rejestracje poidoor5/7/9.lua w actions.xml. Sprawdz w grze: w tym miejscu nie ma drzwi, przejscie robia teleporty. Mozesz oznaczyc naprawiony.

Verdict: NAPRAWIONE I NA PRODUKCJI (restart 14:21). Log: '>> Drabiny (reczne): nadano actionid 1 z 1'. Drabina 32319,32275,8 ma teraz actionid 51072 -> other/drabina-reczna.lua teleportuje na czysty kafelek 32319,32275,7 (zamiast na schody w dol 411). Test: Use (prawy) na drabine -> wchodzisz do gory i zostajesz.

Verdict: Potwierdzone - szczegolny przypadek zgloszenia 69. slain undead dragon (12831) ma w items.otb flagi 0, czyli brak flagi PRZESUWALNY (64), a jego grafika 12596 ma w Tibia.dat atrybut "nieprzesuwalny". Obie strony zgodnie zabraniaja ruszenia zwlok. Drugie stadium tych samych zwlok, 12938 (grafika 12695), flage 64 ma i atrybutu blokujacego nie ma - wiec po rozlozeniu sie zwloki nagle daja sie przesunac. To samo dotyczy 109 innych rodzajow zwlok. Naprawa do uzgodnienia razem ze zgloszeniem 69, bo to jedna poprawka. | NANIESIONE 2026-09-10 razem ze zgloszeniem 69 - slain undead dragon (12831) ma juz flage PRZESUWALNY, a jego grafika 12596 nie jest juz oznaczona jako nieprzesuwalna.

Verdict: Potwierdzone, a przyczyna byla po stronie klienta, nie serwera. dead juggernaut (10322) wskazuje grafike 10184, a ten wpis w Tibia.dat nie mial atrybutu POJEMNIK - klient nie wiedzial, ze to skrzynia, wiec jej nie otwieral. Po 10 sekundach zwloki rozkladaly sie w 12901 (grafika 12660), ktora atrybut miala - i dopiero wtedy dawaly sie otworzyc. Stad wrazenie opoznienia. Serwerowo oba stadia byly poprawne. NANIESIONE 2026-09-10: atrybut dolozony 7 grafikom (10183, 10184, 10185, 10186, 8690, 12867, 5964) - osme zwloki dziela grafike z siodmymi, wiec zalatwione za jednym razem. Objelo dead braindeath, dead juggernaut, slain diabolic imp, slain reaper, dead chakoya, dead seagull, dead ice golem. Plik rozeslany do lustra i obu paczek.

Verdict: Potwierdzone jako usterka zbiorcza. Zeby dalo sie przeciagnac zwloki, musza zgodzic sie dwie strony: items.otb potrzebuje flagi PRZESUWALNY (64), a wpis w Tibia.dat nie moze miec atrybutu nieprzesuwalny. Na 454 rodzaje zwlok 109 nie mialo flagi, a 108 z nich klient dodatkowo blokowal. Dotyczylo podstawowych potworow: dead spider, dead rat, dead wolf, dead orc, dead dragon, slain skeleton. NANIESIONE 2026-09-10: 109 rodzajom dolozono flage w items.otb, 107 grafikom zdjeto atrybut w Tibia.dat - obie strony naraz, bo jedna nic nie daje. Kontrola po zmianie: 0 zwlok bez flagi, 0 blokowanych przez klienta. Nowy Tibia.dat rozeslany do lustra aktualizacji, obu klientow testowych i obu paczek (windowsowej i macowej).

Verdict: Potwierdzone. dead quara (12813) mial decayTo=5522, a 5522 to u nas catapult - stad zamiana zwlok w katapulte po 10 sekundach. Przyczyna: scalanie wpisalo do decayTo WLASNY numer przedmiotu z 8.6 zamiast numeru celu (w 8.6 numer 5522 to wlasnie te zwloki). Ten sam blad mialo 17 rodzajow zwlok, m.in. dead blood crab, dead toad, dead mammoth, slain dark torturer. NANIESIONE 2026-09-10: poprawione w items/77/items.xml. Tam, gdzie nasz pack ma nastepne stadium, decayTo wskazuje na nie (slain undead dragon -> 12939, slain ice golem -> 12969, slain dark torturer -> 12951). Tam, gdzie stadium nie ma - bo scalanie zaimportowalo tylko pierwsze - decayTo=0 i czas 900 s, zeby dalo sie splądrowac przed zniknieciem. Zostal jeden przypadek, slain mummy -> mummy disguise, ale to nie usterka: w 8.6 jest dokladnie tak samo.

Verdict: NAPRAWIONE (czeka na test + /reload actions lub restart). Dzwignia behemota (1945, aid 56267) usuwala przedmiot ze STACKPOS 1 na 5 kafelkach bramy (33295-33299,31677,z15). Scalanie dodalo na 3 z nich obramowania (4456/4460/4464), ktore wskoczyly na stackpos 1 PRZED kamien 1304 - wiec dzwignia kasowala obramowanie, nie kamien, i brama otwierala sie tylko w 2 z 5 miejsc (dlatego 'przestalo dzialac'). Przepisany other/behe_lever.lua: bierze kamien po ITEMID (getTileItemById), odpornie na stackpos, dwukierunkowo (otwiera i zamyka). Kamienie bramy na mapie potwierdzone. Kopia: C:/local/kopie-otb/behe_lever.lua.przed-stackpos-2026-10-08.

Verdict: Potwierdzone i naprawione. Przyczyna: items.xml mial poprawne shootType (np. "infernalbolt"), ale silnik ich NIE ZNA - jego slownik w tools.cpp ma 15 nazw z czasow 7.72. Nieznana nazwa byla odrzucana z ostrzezeniem przy starcie, efekt zostawal zerowy i renderowal sie jako wlocznia. Dotyczylo 15 rodzajow amunicji, nie tylko infernal boltow. Klient ma tylko 15 pociskow (komplet 7.72), wiec dodanie nazw do silnika nic by nie dalo - nie ma czego rysowac. Naprawa: przypisanie najblizszego istniejacego efektu w items.xml (infernalbolt->powerbolt, piercingbolt->bolt, strzaly->arrow/burstarrow, gwiazdy->throwingstar, royalspear->spear, ice->snowball, earth->poison). Ostrzezen przy starcie: 15 -> 0. UWAGA: kilka rodzajow dzieli teraz jedna animacje; rozroznienie wymagaloby doklejenia pociskow z 8.6 i przebudowy serwera. Potwierdzone w grze 2026-09-03.

Verdict: Potwierdzone, przyczyna ustalona i szersza niz to miejsce. Na 33199,31640,10 stoi sciana 3584, a w mapie zrodlowej 8.6 sa tam PAJECZYNY (8055) - przeszkoda, przez ktora da sie przejsc. Scalanie zamienilo ja na lita sciane i zablokowalo zejscie po schodach (459) tuz za nia. Audyt calej mapy: sciana 3584 wystepuje u nas w 978 miejscach, z czego w 971 zrodlo 8.6 ma pajeczyny. Czyli praktycznie kazde wystapienie tego numeru to zle przemapowana pajeczyna, blokujaca przejscie. Numer 8055 istnieje w naszym items.otb, wiec naprawa jest wykonalna skryptem startowym: podmiana 3584 na 8055 w tych 971 miejscach, bez ruszania world.otbm. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Odrzucone - to nie usterka i NIE skutek mojej wczorajszej zmiany. Sprawdzilem: plik monster/Bio-Elementals/defiler.xml parsuje sie poprawnie, a nadany przeze mnie corpse=12845 ("defiler remains") istnieje w items.otb i ma komplet atrybutow pojemnika. Powod, dla ktorego potwor nie ginie, jest w jego wlasnej definicji: 3650 zycia, element earthPercent=100 (calkowita odpornosc na obrazenia ziemi/trucizny) oraz zaklecie leczace na 340-390 co 2 sekundy z szansa 10 procent. Atakowany trucizna nie traci ani punktu i sie doleczaa. Slaby punkt: firePercent=-25, czyli ogien zadaje mu o 25 procent wiecej. Jesli uwazasz, ze leczenie jest za mocne, to osobna decyzja o balansie.

Verdict: Potwierdzone i JUZ POPRAWIONE. Moj wczorajszy wybor byl bledny: ustawilem fury corpse=3058, czyli zwloki MESKIE. Render obu kandydatow potwierdza uwage - 3058 to cialo meskie, 3065 kobiece (tego samego uzywa Amazon). Zmienione na 3065. Wchodzi po restarcie serwera. Druga czesc uwagi (zeby nie zmienial sprite pod soba) - przedmiot 3065 jest pojemnikiem ze zwlokami, nie gruntem, wiec podlogi nie zastepuje. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Odrzucone - grafiki sa poprawne. Sprawdzone co do bajtu wobec oryginalnego klienta 7.6: sciana 3576 (clientid 1723), podlogi 860 (1006), 882 (1090) i 317 (317) maja u nas identyczna zawartosc grafiki i ten sam clientid co w oryginale. To nie jest usterka warstwy graficznej, tylko kompozycja mapy po scalaniu - ta sama konkluzja co przy zgloszeniach 7, 11, 18 i pozostalych z tej grupy.

Verdict: Odrzucone - grafiki sa poprawne. Sprawdzone co do bajtu wobec oryginalnego klienta 7.6: sciana 3576 (clientid 1723), podlogi 860 (1006), 882 (1090) i 317 (317) maja u nas identyczna zawartosc grafiki i ten sam clientid co w oryginale. To nie jest usterka warstwy graficznej, tylko kompozycja mapy po scalaniu - ta sama konkluzja co przy zgloszeniach 7, 11, 18 i pozostalych z tej grupy.

Verdict: Odrzucone - to nie zgloszenie usterki, tylko potwierdzenie, ze teleport dziala poprawnie. Dziekuje, przydatne przy weryfikacji naprawy 124 teleportow z 31 sierpnia.

Verdict: Odrzucone - grafiki sa poprawne. Sprawdzone co do bajtu wobec oryginalnego klienta 7.6: sciana 3576 (clientid 1723), podlogi 860 (1006), 882 (1090) i 317 (317) maja u nas identyczna zawartosc grafiki i ten sam clientid co w oryginale. To nie jest usterka warstwy graficznej, tylko kompozycja mapy po scalaniu - ta sama konkluzja co przy zgloszeniach 7, 11, 18 i pozostalych z tej grupy.

Verdict: KOREKTA wczesniejszego werdyktu. Napisalem, ze corpse=12818 ("demon dust") u bossow to blad numeracji po scalaniu - to NIEPRAWDA. Most przez nazwe (numer 8.6 -> nazwa -> nasz numer) pokazal, ze paczka zrodlowa 8.6 ma dla Annihilona, Ghazbarana, Golgordana, Hellgoraka, Latrivana, Madareth i Morgarotha corpse=6068, czyli wlasnie "demon dust". Nasza wartosc 12818 jest poprawnym odpowiednikiem tego numeru. Scalanie niczego tu nie zepsulo. Jesli ciala bossa faktycznie nie da sie otworzyc i przepada lup, przyczyna jest inna - najpewniej brak atrybutu containerSize przy przedmiocie 12818 - i to wymaga osobnego sprawdzenia. Zgloszenie zostaje potwierdzone, ale przyczyna NIE jest ustalona.

Verdict: KOREKTA wczesniejszego werdyktu. Napisalem, ze corpse=12818 ("demon dust") u bossow to blad numeracji po scalaniu - to NIEPRAWDA. Most przez nazwe (numer 8.6 -> nazwa -> nasz numer) pokazal, ze paczka zrodlowa 8.6 ma dla Annihilona, Ghazbarana, Golgordana, Hellgoraka, Latrivana, Madareth i Morgarotha corpse=6068, czyli wlasnie "demon dust". Nasza wartosc 12818 jest poprawnym odpowiednikiem tego numeru. Scalanie niczego tu nie zepsulo. Jesli ciala bossa faktycznie nie da sie otworzyc i przepada lup, przyczyna jest inna - najpewniej brak atrybutu containerSize przy przedmiocie 12818 - i to wymaga osobnego sprawdzenia. Zgloszenie zostaje potwierdzone, ale przyczyna NIE jest ustalona.

Verdict: Potwierdzone. Massive Water Elemental ma w monster/Hydro-Elementals/ ustawione look type="11" - to stroj z bazowego zakresu 7.6, a nie wlasny stroj z 8.6 (klient ma 553 stroje). Stad zupelnie inny wyglad. To ta sama klasa usterki co zepsuta ropucha (looktype 222). Naprawa: ustalic wlasciwy looktype i poprawic. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: NAPRAWIONE (czeka na Twoj test + /reload monsters lub restart). Zwloki WSZYSTKICH bossow demonow byly ustawione na corpse=12818 'demon dust' - a to STAKOWALNY MATERIAL (nagroda z taska demona {12818,60}), nie zwloki, wiec sie nie otwieraly. Nie mozna ruszyc 12818 (zepsuloby material), wiec przestawilem corpse na 2916 'slain demon' (to samo co zwyklego Demona: grupa container, NIE stackable). Poprawione 13 plikow: annihilon, Freegoiz, ghazbaran, golgordan, hellgorak, Kraknaknork Demon, latrivan, madareth, morgaroth, ushuriel, Verminor, Zoralurk, zugurosh. Kopie: C:/local/kopie-otb/bossy-corpse-2026-10-08.

Verdict: Potwierdzone czesciowo. W promieniu 12 kratek od 33322,31591,15 spawny sa, ale na pietrze 14 (Demon x2) - na pietrze 15, gdzie stoisz, nie ma zadnego. Komnata questu jest pusta. Naprawa: dodac spawny na wlasciwym pietrze. Czeka na zgode. | NAPRAWIONE: komnata na 33322,31592,15 obsadzona - 4 demony i 6 banshee. Wczesniej byla pusta, bo jedyne demony staly pietro nizej. Potwierdzone w grze 2026-09-05.

Verdict: Odrzucone - to nie zgloszenie usterki, tylko propozycja albo pytanie. Zapisane, ale przez system bledow nie da sie tego prowadzic; jesli ma powstac, potrzebna osobna decyzja co i gdzie dodac.

Verdict: Potwierdzone. Teleport na 33143,31639,11 (przedmiot 5023, magic forcefield) ma w mapie zapisany cel 0,0,0 - czyli nie prowadzi nigdzie. Trzeba ustalic wlasciwy cel i go wpisac. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Odrzucone - to nie zgloszenie usterki, tylko propozycja albo pytanie. Zapisane, ale przez system bledow nie da sie tego prowadzic; jesli ma powstac, potrzebna osobna decyzja co i gdzie dodac.

Verdict: Odrzucone - to nie zgloszenie usterki, tylko propozycja albo pytanie. Zapisane, ale przez system bledow nie da sie tego prowadzic; jesli ma powstac, potrzebna osobna decyzja co i gdzie dodac.

Verdict: Potwierdzone. Ta sama przyczyna co zgloszenia 9 i 10. Audyt calego actions.xml (audyt-uid.lua): ze 263 zarejestrowanych numerow uniqueid az 144 NIE ISTNIEJE na naszej mapie, a wszystkie sa w oryginalnej mapie 7.6 - scalanie 8.6 przenioslo obiekty, ale zgubilo ich numery. Dotyczy to praktycznie wszystkich questow na serwerze, nie tylko tego. Plan naprawy w C:/local/plan-uid.txt: 48 przypadkow wymaga samego nadania uid, 78 takze postawienia przedmiotu, 18 pozycji nie ma na naszej mapie. Naprawa jednym skryptem startowym, jak przy minotaurze. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Odrzucone. Grafiki sprawdzone co do bajtu wobec ORYGINALNEGO klienta 7.6 (skrypt porownaj-lista.lua): podlogi 309, 304, 307, 320, 404, 187, 180, 847, 103, 724, 405 oraz kamienie 3622/3623 i sciana 4438 maja u nas te sama zawartosc grafiki i ten sam clientid co w oryginale. Warstwa graficzna jest w porzadku - to, co razi, to KOMPOZYCJA mapy: scalanie 8.6 rozlozylo inne rodzaje podlog niz oryginal. To nie usterka pliku, tylko wyglad mapy; zmiana wymagalaby decyzji projektowej i edycji mapy w tysiacach miejsc. Ta sama konkluzja co przy zgloszeniu 7.

Verdict: Odrzucone jako usterka - teleport dziala. Na 32360,31784,8 stoi przedmiot 1387 z actionid=30024 i celem 32360,31782,7, czyli dwa kafelki na polnoc i pietro wyzej. To dziala poprawnie; uwaga dotyczy tego, DOKAD ma prowadzic (Carlin zamiast Ab Dendriel), a to decyzja projektowa, nie blad. Jesli cel ma byc inny, podaj wspolrzedne.

Verdict: NAPRAWIONE (to te same drzwi 32824,31969,8 co trzecie drzwi willi Black Knight). Wpis w data/actions/scripts/other/keys.lua QUEST_DRZWI: otwiera sie kluczem o aid 5010, transform -> 5900. ActionID drzwi 1001 jest smieciowy (handler laczy po POZYCJI). Potwierdzone 'dziala' w rozmowie. Mozesz oznaczyc naprawiony.

Verdict: Potwierdzone. W pliku spawnow map-spawn.xml nie ma ANI JEDNEGO wpisu dla "dragon lord" - potwor jest zdefiniowany, ale nigdzie sie nie pojawia. Naprawa wymaga dodania spawnow, czyli decyzji gdzie i ile. Czeka na zgode. | NAPRAWIONE: dodany jeden spawn Dragon Lord na 32778,32146,5 (obszar sprawdzony jako przechodni). Wczesniej ten potwor nie mial ANI JEDNEGO spawnu na calej mapie. Potwierdzone w grze 2026-09-05.

Verdict: Potwierdzone, przyczyna ustalona. W items/77/items.xml arbalest (serverid 5685) ma poprawnie range=6, ale w weapons/weapons.xml zarejestrowane sa jako bron dystansowa TYLKO crossbow (2455) i bow (2456) - arbalesta tam nie ma. Niezarejestrowana bron nie dostaje swojego zasiegu i dziala jak na dystans 1. Naprawa: dopisac jedna linie <distance id="5685" event="function" value="default"/>. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Odrzucone - nie udalo sie potwierdzic. Na podanej pozycji 32830,32243,11 nasza mapa nie ma ZADNEGO kafelka, wiec nie ma tam przedmiotu 1387. Prawdopodobnie pomylka we wspolrzednych; prosze zglosic ponownie stojac na wlasciwym kafelku.

Verdict: Potwierdzone, przyczyna NIE ustalona. Sprawdzilem najbardziej prawdopodobna: corpse dla Lost Soul to 12833, czyli "slain lost soul" - numer poprawny, wiec to nie ten sam blad co przy fury. Wymaga dalszego badania (czas rozkladu, atrybuty pojemnika). | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Potwierdzone. Ta sama przyczyna co zgloszenia 9 i 10. Audyt calego actions.xml (audyt-uid.lua): ze 263 zarejestrowanych numerow uniqueid az 144 NIE ISTNIEJE na naszej mapie, a wszystkie sa w oryginalnej mapie 7.6 - scalanie 8.6 przenioslo obiekty, ale zgubilo ich numery. Dotyczy to praktycznie wszystkich questow na serwerze, nie tylko tego. Plan naprawy w C:/local/plan-uid.txt: 48 przypadkow wymaga samego nadania uid, 78 takze postawienia przedmiotu, 18 pozycji nie ma na naszej mapie. Naprawa jednym skryptem startowym, jak przy minotaurze. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Potwierdzone. Ta sama przyczyna co zgloszenia 9 i 10. Audyt calego actions.xml (audyt-uid.lua): ze 263 zarejestrowanych numerow uniqueid az 144 NIE ISTNIEJE na naszej mapie, a wszystkie sa w oryginalnej mapie 7.6 - scalanie 8.6 przenioslo obiekty, ale zgubilo ich numery. Dotyczy to praktycznie wszystkich questow na serwerze, nie tylko tego. Plan naprawy w C:/local/plan-uid.txt: 48 przypadkow wymaga samego nadania uid, 78 takze postawienia przedmiotu, 18 pozycji nie ma na naszej mapie. Naprawa jednym skryptem startowym, jak przy minotaurze. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Potwierdzone. Audyt zwlok wszystkich 494 potworow (audyt-zwlok.lua): 34 ma atrybut corpse wskazujacy na przedmiot, ktory po scalaniu 8.6 oznacza cos innego, a 6 na numer nieistniejacy. Fury ma corpse=6081, co w naszym items.otb jest przedmiotem "snow". Stad brak ciala po zabiciu. Naprawa: poprawic numer w monster/Demons/fury.xml na wlasciwe zwloki. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Potwierdzone. Audyt zwlok wszystkich 494 potworow (audyt-zwlok.lua): 34 ma atrybut corpse wskazujacy na przedmiot, ktory po scalaniu 8.6 oznacza cos innego, a 6 na numer nieistniejacy. Fury ma corpse=6081, co w naszym items.otb jest przedmiotem "snow". Stad brak ciala po zabiciu. Naprawa: poprawic numer w monster/Demons/fury.xml na wlasciwe zwloki. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Odrzucone - to nie zgloszenie usterki, tylko propozycja albo pytanie. Zapisane, ale przez system bledow nie da sie tego prowadzic; jesli ma powstac, potrzebna osobna decyzja co i gdzie dodac.

Verdict: Odrzucone - to nie zgloszenie usterki, tylko propozycja albo pytanie. Zapisane, ale przez system bledow nie da sie tego prowadzic; jesli ma powstac, potrzebna osobna decyzja co i gdzie dodac.

Verdict: Odrzucone - to nie zgloszenie usterki, tylko propozycja albo pytanie. Zapisane, ale przez system bledow nie da sie tego prowadzic; jesli ma powstac, potrzebna osobna decyzja co i gdzie dodac.

Verdict: Potwierdzone. Ta sama przyczyna co zgloszenia 9 i 10. Audyt calego actions.xml (audyt-uid.lua): ze 263 zarejestrowanych numerow uniqueid az 144 NIE ISTNIEJE na naszej mapie, a wszystkie sa w oryginalnej mapie 7.6 - scalanie 8.6 przenioslo obiekty, ale zgubilo ich numery. Dotyczy to praktycznie wszystkich questow na serwerze, nie tylko tego. Plan naprawy w C:/local/plan-uid.txt: 48 przypadkow wymaga samego nadania uid, 78 takze postawienia przedmiotu, 18 pozycji nie ma na naszej mapie. Naprawa jednym skryptem startowym, jak przy minotaurze. Czeka na zgode. | NAPRAWIONE: skryptu rookdragon.lua NIE BYLO w paczce - napisany od zera na wzor pozostalych questow rookgaardzkich, rejestracja w actions.xml odkomentowana. Martwy smok (2844) stoi na 32179,32223,9 dzieki questy-uid-naprawa.lua, nagroda copper shield 2530, jednorazowo. Potwierdzone w grze 2026-09-03.

Verdict: Potwierdzone. Ta sama przyczyna co zgloszenia 9 i 10. Audyt calego actions.xml (audyt-uid.lua): ze 263 zarejestrowanych numerow uniqueid az 144 NIE ISTNIEJE na naszej mapie, a wszystkie sa w oryginalnej mapie 7.6 - scalanie 8.6 przenioslo obiekty, ale zgubilo ich numery. Dotyczy to praktycznie wszystkich questow na serwerze, nie tylko tego. Plan naprawy w C:/local/plan-uid.txt: 48 przypadkow wymaga samego nadania uid, 78 takze postawienia przedmiotu, 18 pozycji nie ma na naszej mapie. Naprawa jednym skryptem startowym, jak przy minotaurze. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Potwierdzone. Ta sama przyczyna co zgloszenia 9 i 10. Audyt calego actions.xml (audyt-uid.lua): ze 263 zarejestrowanych numerow uniqueid az 144 NIE ISTNIEJE na naszej mapie, a wszystkie sa w oryginalnej mapie 7.6 - scalanie 8.6 przenioslo obiekty, ale zgubilo ich numery. Dotyczy to praktycznie wszystkich questow na serwerze, nie tylko tego. Plan naprawy w C:/local/plan-uid.txt: 48 przypadkow wymaga samego nadania uid, 78 takze postawienia przedmiotu, 18 pozycji nie ma na naszej mapie. Naprawa jednym skryptem startowym, jak przy minotaurze. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Odrzucone. Grafiki sprawdzone co do bajtu wobec ORYGINALNEGO klienta 7.6 (skrypt porownaj-lista.lua): podlogi 309, 304, 307, 320, 404, 187, 180, 847, 103, 724, 405 oraz kamienie 3622/3623 i sciana 4438 maja u nas te sama zawartosc grafiki i ten sam clientid co w oryginale. Warstwa graficzna jest w porzadku - to, co razi, to KOMPOZYCJA mapy: scalanie 8.6 rozlozylo inne rodzaje podlog niz oryginal. To nie usterka pliku, tylko wyglad mapy; zmiana wymagalaby decyzji projektowej i edycji mapy w tysiacach miejsc. Ta sama konkluzja co przy zgloszeniu 7.

Verdict: Potwierdzone. Na kafelku lezy przedmiot z zestawu 8.6 (debris, numery 6023/6026/6028/6029/6035) polozony na rookgaardzkiej ziemi 103. To slad po scalaniu - w oryginalnej mapie 7.6 tych obiektow tam nie ma. Sama grafika jest poprawna, ale obiekt nie pasuje do otoczenia. Naprawa wymaga decyzji: zdjac te obiekty skryptem startowym (jak obiekty-naprawa.lua) czy zostawic. Czeka na zgode. | NAPRAWIONE: zdjete 665 obiektow debris z 8.6 lezacych w Rookgaard na kafelkach, ktore w oryginale 7.6 byly puste (skrypt startowy debris-naprawa.lua, dane w lib/065-debris.lua). Zakres celowo zawezony: debris to normalna dekoracja, 40105 sztuk poza Rookgaard; pominieto 275 pozycji gdzie w oryginale cos lezalo i 114 na terenie, ktorego w 7.6 nie bylo. Potwierdzone w grze 2026-09-05.

Verdict: Odrzucone. Grafiki sprawdzone co do bajtu wobec ORYGINALNEGO klienta 7.6 (skrypt porownaj-lista.lua): podlogi 309, 304, 307, 320, 404, 187, 180, 847, 103, 724, 405 oraz kamienie 3622/3623 i sciana 4438 maja u nas te sama zawartosc grafiki i ten sam clientid co w oryginale. Warstwa graficzna jest w porzadku - to, co razi, to KOMPOZYCJA mapy: scalanie 8.6 rozlozylo inne rodzaje podlog niz oryginal. To nie usterka pliku, tylko wyglad mapy; zmiana wymagalaby decyzji projektowej i edycji mapy w tysiacach miejsc. Ta sama konkluzja co przy zgloszeniu 7.

Verdict: Potwierdzone, ta sama przyczyna co zgloszenie 23. Spawn orka stoi na 31972,32161,8, a zglaszany ork pojawil sie na 31972,32164,8 - w promieniu spawnu, ale na kafelku, ktory po scalaniu jest sciana. | NAPRAWIONE. Przyczyna byla podwojna: promien spawnu siegal w teren, ktory po scalaniu jest lita sciana, a w tej samej okolicy staly KOLEJNE spawny z tym samym problemem, ktorych pierwsza poprawka nie objela. Hurtowy audyt calego pliku spawnow: z 42160 potworow 1876 rodzilo sie w scianie; 829 przesunieto w obrebie wlasnego promienia. Te tutaj nalezaly do 1765, ktorym w promieniu zabraklo miejsca - dla nich poszerzono poszukiwanie do 8 kratek i przesunieto srodek spawnu. Potwierdzone w grze 2026-09-05.

Verdict: Odrzucone. Grafiki sprawdzone co do bajtu wobec ORYGINALNEGO klienta 7.6 (skrypt porownaj-lista.lua): podlogi 309, 304, 307, 320, 404, 187, 180, 847, 103, 724, 405 oraz kamienie 3622/3623 i sciana 4438 maja u nas te sama zawartosc grafiki i ten sam clientid co w oryginale. Warstwa graficzna jest w porzadku - to, co razi, to KOMPOZYCJA mapy: scalanie 8.6 rozlozylo inne rodzaje podlog niz oryginal. To nie usterka pliku, tylko wyglad mapy; zmiana wymagalaby decyzji projektowej i edycji mapy w tysiacach miejsc. Ta sama konkluzja co przy zgloszeniu 7.

Verdict: Odrzucone. Grafiki sprawdzone co do bajtu wobec ORYGINALNEGO klienta 7.6 (skrypt porownaj-lista.lua): podlogi 309, 304, 307, 320, 404, 187, 180, 847, 103, 724, 405 oraz kamienie 3622/3623 i sciana 4438 maja u nas te sama zawartosc grafiki i ten sam clientid co w oryginale. Warstwa graficzna jest w porzadku - to, co razi, to KOMPOZYCJA mapy: scalanie 8.6 rozlozylo inne rodzaje podlog niz oryginal. To nie usterka pliku, tylko wyglad mapy; zmiana wymagalaby decyzji projektowej i edycji mapy w tysiacach miejsc. Ta sama konkluzja co przy zgloszeniu 7.

Verdict: Potwierdzone. Ta sama przyczyna co zgloszenia 9 i 10. Audyt calego actions.xml (audyt-uid.lua): ze 263 zarejestrowanych numerow uniqueid az 144 NIE ISTNIEJE na naszej mapie, a wszystkie sa w oryginalnej mapie 7.6 - scalanie 8.6 przenioslo obiekty, ale zgubilo ich numery. Dotyczy to praktycznie wszystkich questow na serwerze, nie tylko tego. Plan naprawy w C:/local/plan-uid.txt: 48 przypadkow wymaga samego nadania uid, 78 takze postawienia przedmiotu, 18 pozycji nie ma na naszej mapie. Naprawa jednym skryptem startowym, jak przy minotaurze. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Odrzucone. Grafiki sprawdzone co do bajtu wobec ORYGINALNEGO klienta 7.6 (skrypt porownaj-lista.lua): podlogi 309, 304, 307, 320, 404, 187, 180, 847, 103, 724, 405 oraz kamienie 3622/3623 i sciana 4438 maja u nas te sama zawartosc grafiki i ten sam clientid co w oryginale. Warstwa graficzna jest w porzadku - to, co razi, to KOMPOZYCJA mapy: scalanie 8.6 rozlozylo inne rodzaje podlog niz oryginal. To nie usterka pliku, tylko wyglad mapy; zmiana wymagalaby decyzji projektowej i edycji mapy w tysiacach miejsc. Ta sama konkluzja co przy zgloszeniu 7.

Verdict: Potwierdzone. Spawn wilkow stoi na 31979,32192,8 i jego promien obejmuje zglaszane miejsce, ale scalanie 8.6 zmienilo teren i czesc kafelkow w promieniu to teraz sciana. Potwor tworzony jest na kafelku blokujacym i wyglada, jakby byl "w scianie". Naprawa: przesunac srodek spawnu albo zmniejszyc promien w map-spawn.xml. Czeka na zgode. | NAPRAWIONE. Przyczyna byla podwojna: promien spawnu siegal w teren, ktory po scalaniu jest lita sciana, a w tej samej okolicy staly KOLEJNE spawny z tym samym problemem, ktorych pierwsza poprawka nie objela. Hurtowy audyt calego pliku spawnow: z 42160 potworow 1876 rodzilo sie w scianie; 829 przesunieto w obrebie wlasnego promienia. Te tutaj nalezaly do 1765, ktorym w promieniu zabraklo miejsca - dla nich poszerzono poszukiwanie do 8 kratek i przesunieto srodek spawnu. Potwierdzone w grze 2026-09-05.

Verdict: Odrzucone. Grafiki sprawdzone co do bajtu wobec ORYGINALNEGO klienta 7.6 (skrypt porownaj-lista.lua): podlogi 309, 304, 307, 320, 404, 187, 180, 847, 103, 724, 405 oraz kamienie 3622/3623 i sciana 4438 maja u nas te sama zawartosc grafiki i ten sam clientid co w oryginale. Warstwa graficzna jest w porzadku - to, co razi, to KOMPOZYCJA mapy: scalanie 8.6 rozlozylo inne rodzaje podlog niz oryginal. To nie usterka pliku, tylko wyglad mapy; zmiana wymagalaby decyzji projektowej i edycji mapy w tysiacach miejsc. Ta sama konkluzja co przy zgloszeniu 7.

Verdict: Odrzucone - to nie zgloszenie usterki, tylko propozycja albo pytanie. Zapisane, ale przez system bledow nie da sie tego prowadzic; jesli ma powstac, potrzebna osobna decyzja co i gdzie dodac.

Verdict: Odrzucone. Grafiki sprawdzone co do bajtu wobec ORYGINALNEGO klienta 7.6 (skrypt porownaj-lista.lua): podlogi 309, 304, 307, 320, 404, 187, 180, 847, 103, 724, 405 oraz kamienie 3622/3623 i sciana 4438 maja u nas te sama zawartosc grafiki i ten sam clientid co w oryginale. Warstwa graficzna jest w porzadku - to, co razi, to KOMPOZYCJA mapy: scalanie 8.6 rozlozylo inne rodzaje podlog niz oryginal. To nie usterka pliku, tylko wyglad mapy; zmiana wymagalaby decyzji projektowej i edycji mapy w tysiacach miejsc. Ta sama konkluzja co przy zgloszeniu 7.

Verdict: Odrzucone - juz naprawione, duplikat zgloszen 1, 3, 4 i 6. Sprawdzone dzis ponownie: serverid 490 wskazuje w items.otb na clientid 4446, a ten rysuje sie grafika 10437 - szara pionowa sciana, nie woda (render zalaczony w scratchpadzie). Jesli u siebie nadal widzisz wode, to klient nie dociagnal aktualizacji - uruchom go ponownie.

Verdict: Odrzucone. Grafiki sprawdzone co do bajtu wobec ORYGINALNEGO klienta 7.6 (skrypt porownaj-lista.lua): podlogi 309, 304, 307, 320, 404, 187, 180, 847, 103, 724, 405 oraz kamienie 3622/3623 i sciana 4438 maja u nas te sama zawartosc grafiki i ten sam clientid co w oryginale. Warstwa graficzna jest w porzadku - to, co razi, to KOMPOZYCJA mapy: scalanie 8.6 rozlozylo inne rodzaje podlog niz oryginal. To nie usterka pliku, tylko wyglad mapy; zmiana wymagalaby decyzji projektowej i edycji mapy w tysiacach miejsc. Ta sama konkluzja co przy zgloszeniu 7.

Verdict: Potwierdzone. Na kafelku lezy przedmiot z zestawu 8.6 (debris, numery 6023/6026/6028/6029/6035) polozony na rookgaardzkiej ziemi 103. To slad po scalaniu - w oryginalnej mapie 7.6 tych obiektow tam nie ma. Sama grafika jest poprawna, ale obiekt nie pasuje do otoczenia. Naprawa wymaga decyzji: zdjac te obiekty skryptem startowym (jak obiekty-naprawa.lua) czy zostawic. Czeka na zgode. | NAPRAWIONE: zdjete 665 obiektow debris z 8.6 lezacych w Rookgaard na kafelkach, ktore w oryginale 7.6 byly puste (skrypt startowy debris-naprawa.lua, dane w lib/065-debris.lua). Zakres celowo zawezony: debris to normalna dekoracja, 40105 sztuk poza Rookgaard; pominieto 275 pozycji gdzie w oryginale cos lezalo i 114 na terenie, ktorego w 7.6 nie bylo. Potwierdzone w grze 2026-09-05.

Verdict: Odrzucone. Spawny szczurow w tej okolicy istnieja - najblizszy to 2 sztuki na 32077,32182,9. Nie znalazlem braku w pliku spawnow; jesli szczura faktycznie nie ma, przyczyna jest inna niz brak wpisu (np. kafelek zablokowany po scalaniu) i potrzebne jest dokladniejsze wskazanie miejsca.

Verdict: Potwierdzone. Ta sama przyczyna co zgloszenia 9 i 10. Audyt calego actions.xml (audyt-uid.lua): ze 263 zarejestrowanych numerow uniqueid az 144 NIE ISTNIEJE na naszej mapie, a wszystkie sa w oryginalnej mapie 7.6 - scalanie 8.6 przenioslo obiekty, ale zgubilo ich numery. Dotyczy to praktycznie wszystkich questow na serwerze, nie tylko tego. Plan naprawy w C:/local/plan-uid.txt: 48 przypadkow wymaga samego nadania uid, 78 takze postawienia przedmiotu, 18 pozycji nie ma na naszej mapie. Naprawa jednym skryptem startowym, jak przy minotaurze. Czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Potwierdzone. Na kafelku lezy przedmiot z zestawu 8.6 (debris, numery 6023/6026/6028/6029/6035) polozony na rookgaardzkiej ziemi 103. To slad po scalaniu - w oryginalnej mapie 7.6 tych obiektow tam nie ma. Sama grafika jest poprawna, ale obiekt nie pasuje do otoczenia. Naprawa wymaga decyzji: zdjac te obiekty skryptem startowym (jak obiekty-naprawa.lua) czy zostawic. Czeka na zgode. | NAPRAWIONE: zdjete 665 obiektow debris z 8.6 lezacych w Rookgaard na kafelkach, ktore w oryginale 7.6 byly puste (skrypt startowy debris-naprawa.lua, dane w lib/065-debris.lua). Zakres celowo zawezony: debris to normalna dekoracja, 40105 sztuk poza Rookgaard; pominieto 275 pozycji gdzie w oryginale cos lezalo i 114 na terenie, ktorego w 7.6 nie bylo. Potwierdzone w grze 2026-09-05.

Verdict: Potwierdzone. Na kafelku lezy przedmiot z zestawu 8.6 (debris, numery 6023/6026/6028/6029/6035) polozony na rookgaardzkiej ziemi 103. To slad po scalaniu - w oryginalnej mapie 7.6 tych obiektow tam nie ma. Sama grafika jest poprawna, ale obiekt nie pasuje do otoczenia. Naprawa wymaga decyzji: zdjac te obiekty skryptem startowym (jak obiekty-naprawa.lua) czy zostawic. Czeka na zgode. | NAPRAWIONE: zdjete 665 obiektow debris z 8.6 lezacych w Rookgaard na kafelkach, ktore w oryginale 7.6 byly puste (skrypt startowy debris-naprawa.lua, dane w lib/065-debris.lua). Zakres celowo zawezony: debris to normalna dekoracja, 40105 sztuk poza Rookgaard; pominieto 275 pozycji gdzie w oryginale cos lezalo i 114 na terenie, ktorego w 7.6 nie bylo. Potwierdzone w grze 2026-09-05.

Verdict: Potwierdzone. Na kafelku lezy przedmiot z zestawu 8.6 (debris, numery 6023/6026/6028/6029/6035) polozony na rookgaardzkiej ziemi 103. To slad po scalaniu - w oryginalnej mapie 7.6 tych obiektow tam nie ma. Sama grafika jest poprawna, ale obiekt nie pasuje do otoczenia. Naprawa wymaga decyzji: zdjac te obiekty skryptem startowym (jak obiekty-naprawa.lua) czy zostawic. Czeka na zgode. | NAPRAWIONE: zdjete 665 obiektow debris z 8.6 lezacych w Rookgaard na kafelkach, ktore w oryginale 7.6 byly puste (skrypt startowy debris-naprawa.lua, dane w lib/065-debris.lua). Zakres celowo zawezony: debris to normalna dekoracja, 40105 sztuk poza Rookgaard; pominieto 275 pozycji gdzie w oryginale cos lezalo i 114 na terenie, ktorego w 7.6 nie bylo. Potwierdzone w grze 2026-09-05.

Verdict: Odrzucone. Grafiki sprawdzone co do bajtu wobec ORYGINALNEGO klienta 7.6 (skrypt porownaj-lista.lua): podlogi 309, 304, 307, 320, 404, 187, 180, 847, 103, 724, 405 oraz kamienie 3622/3623 i sciana 4438 maja u nas te sama zawartosc grafiki i ten sam clientid co w oryginale. Warstwa graficzna jest w porzadku - to, co razi, to KOMPOZYCJA mapy: scalanie 8.6 rozlozylo inne rodzaje podlog niz oryginal. To nie usterka pliku, tylko wyglad mapy; zmiana wymagalaby decyzji projektowej i edycji mapy w tysiacach miejsc. Ta sama konkluzja co przy zgloszeniu 7.

Verdict: Potwierdzony - ta sama przyczyna co zgloszenie 9. Skrzynia obok gracza (1740 na 32124,32063,12) nie ma zadnego uniqueid, wiec nie jest zwiazana ze skryptem. Nagrode wydaje "rook/minotaur hell quest/carlin sword.lua", podpiety pod uniqueid 3020; w oryginale 7.6 numer ten mial skrzynka 1741 na 32122,32063,12, ktora na naszej mapie zostala zastapiona przedmiotem 3613 (clientid 1857). Dodatkowo sam skrypt jest zepsuty: doPlayerAddItem(container,2395,1) - "container" to zmienna nieistniejaca, powinno byc cid. Naprawa opisana, czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: Potwierdzony. Quest opiera sie na trzech pojemnikach o uniqueid 3020 (carlin sword), 3021 (fishing rod), 3022 (arrow) - actions.xml wiersze 126-128. Na naszej mapie ZADEN z tych numerow nie wystepuje - scalanie z 8.6 zdjelo uniqueid. W oryginale 7.6 sa to skrzynki 1741 na 32122,32063,12 / 32130,32066,12 / 32127,32065,12. U nas dwie z nich stoja (32130,32066,12 i 32127,32065,12), ale bez numeru, a trzecia zostala zastapiona przedmiotem 3613. Druga, niezalezna wada: skrypty "carlin sword.lua" i "fishing rod.lua" wolaja doPlayerAddItem(container,...) zamiast (cid,...) - zmienna "container" nie istnieje, wiec nagroda nie zostalaby wydana nawet po naprawie mapy. Naprawa opisana, czeka na zgode. | POTWIERDZONE W GRZE przez GM 2026-09-03 - zamkniete.

Verdict: NAPRAWIONE i sprawdzone w grze. Postac miala ZERO przedmiotow (pusta tabela player_items) przy ustawionym znaczniku wyprawki 121010 - czyli skrypt uznal, ze rzeczy juz wydal. Wina lezala w kolejnosci: data/lib/065-ekwipunek-startowy.lua ustawial znacznik PRZED wydaniem przedmiotow, wiec jedno nieudane wydanie zostawialo gracza z pustymi rekami na zawsze. Poprawki: (1) znacznik ustawiany dopiero PO utworzeniu plecaka - nieudana proba powtorzy sie przy nastepnym logowaniu, (2) zawartosc trafia wprost do plecaka przez doAddContainerItem zamiast do slotow ekwipunku, (3) canDropOnMap=false, bo onLogin wykonuje sie zanim postac trafi na mape i przedmiot bez miejsca byl po cichu kasowany - tak gineli rapier i wooden shield u WSZYSTKICH nowych postaci, (4) nieudane wydania trafiaja do logu serwera. Sprawdzone na swiezej postaci: plecak zalozony, w srodku komplet - club, rapier, wooden shield, chleb x5, pochodnia. Twojej postaci wyczyscilem znacznik, wiec wyprawke dostaniesz przy najblizszym we

Verdict: ZBADANE - dziala zgodnie z zamyslem mapy, nie jest to usterka. Serverid 4438 "wall" to jedno z dwoch podstawowych wypelnien skalnych mapy: lezy jako grunt na 568685 kafelkach, z czego 323799 bylo juz w oryginalnej mapie 7.6. Drugim jest 101 "earth" - 3256958 kafelkow. Oba maja identyczne flagi (BLOCK_SOLID). Nasza grafika 4438 (clientid 4427, sprite 4224) jest co do bajtu identyczna z oryginalnym pakietem 7.6 - scalanie z 8.6 niczego tu nie zepsulo. Styk szarej skaly z brazowa ziemia to normalny element budowy mapy: samo pietro z=8 ma 7529 takich miejsc, z=9 kolejne 3323. We wskazanym punkcie 4438 tworzy masyw 32022-32032 x 32188-32201 z wykutym w srodku pokojem o podlodze 431 "stone floor" - czyli kamienna budowla w ziemi. Podmiana tej grafiki zmienilaby wyglad 4438 w 568 tys. miejsc na calej mapie.

Verdict: NAPRAWIONE i OBEJRZANE W GRZE. Przyczyna byla w moscie serverid -> clientid w items.otb, nie w grafikach. Mapa przyszla z 8.6 i przy konwersji te przedmioty dopasowano po grafice do numerow 7.6, ktore sa WODA: serverid 490 "wall" wskazywal clientid 618, a 618 to w kliencie 7.6 animowana woda (16 klatek, wzor 4x2, grafiki 106-113). Dowod, ze to skutek konwersji: oryginalna mapa 7.6 nie uzywa zadnego z tych 19 numerow ANI RAZU, a nasza uzywa ich 2921 razy i zawsze jako przedmiot na kafelku, nigdy jako grunt - wiec zadna prawdziwa woda z nich nie korzystala i przestawienie bylo bezpieczne. Kierunek kazdej sciany dobrany z ulozenia na mapie (490 ma 1025 sasiadow w pionie i 0 w poziomie -> grafika pionowa 4446; 627 ma 221 w poziomie -> pozioma 4445). Sprawdzone: liczba przedmiotow w items.otb bez zmian (12932), zmienionych dokladnie 19 wpisow, dlugosc pliku bez zmian, wszystkie numery w zakresie klienta. Po restarcie serwera kafelek 32092 wyglada jak szara kamienna sciana. Audyt calej mapy

Verdict: Sama latarnia byla sprawna - jej grafika to granatowy slupek, tylko srednia barwa wygladala jak woda. Woda brala sie ze sciany 490 na tym samym kafelku (32084,32190,7). NAPRAWIONE i OBEJRZANE W GRZE. Przyczyna byla w moscie serverid -> clientid w items.otb, nie w grafikach. Mapa przyszla z 8.6 i przy konwersji te przedmioty dopasowano po grafice do numerow 7.6, ktore sa WODA: serverid 490 "wall" wskazywal clientid 618, a 618 to w kliencie 7.6 animowana woda (16 klatek, wzor 4x2, grafiki 106-113). Dowod, ze to skutek konwersji: oryginalna mapa 7.6 nie uzywa zadnego z tych 19 numerow ANI RAZU, a nasza uzywa ich 2921 razy i zawsze jako przedmiot na kafelku, nigdy jako grunt - wiec zadna prawdziwa woda z nich nie korzystala i przestawienie bylo bezpieczne. Kierunek kazdej sciany dobrany z ulozenia na mapie (490 ma 1025 sasiadow w pionie i 0 w poziomie -> grafika pionowa 4446; 627 ma 221 w poziomie -> pozioma 4445). Sprawdzone: liczba przedmiotow w items.otb bez zmian (12932), zmienionych d

Verdict: NAPRAWIONE i OBEJRZANE W GRZE. Przyczyna byla w moscie serverid -> clientid w items.otb, nie w grafikach. Mapa przyszla z 8.6 i przy konwersji te przedmioty dopasowano po grafice do numerow 7.6, ktore sa WODA: serverid 490 "wall" wskazywal clientid 618, a 618 to w kliencie 7.6 animowana woda (16 klatek, wzor 4x2, grafiki 106-113). Dowod, ze to skutek konwersji: oryginalna mapa 7.6 nie uzywa zadnego z tych 19 numerow ANI RAZU, a nasza uzywa ich 2921 razy i zawsze jako przedmiot na kafelku, nigdy jako grunt - wiec zadna prawdziwa woda z nich nie korzystala i przestawienie bylo bezpieczne. Kierunek kazdej sciany dobrany z ulozenia na mapie (490 ma 1025 sasiadow w pionie i 0 w poziomie -> grafika pionowa 4446; 627 ma 221 w poziomie -> pozioma 4445). Sprawdzone: liczba przedmiotow w items.otb bez zmian (12932), zmienionych dokladnie 19 wpisow, dlugosc pliku bez zmian, wszystkie numery w zakresie klienta. Po restarcie serwera kafelek 32092 wyglada jak szara kamienna sciana. Audyt calej mapy

Verdict: NAPRAWIONE i OBEJRZANE W GRZE. Przyczyna byla w moscie serverid -> clientid w items.otb, nie w grafikach. Mapa przyszla z 8.6 i przy konwersji te przedmioty dopasowano po grafice do numerow 7.6, ktore sa WODA: serverid 490 "wall" wskazywal clientid 618, a 618 to w kliencie 7.6 animowana woda (16 klatek, wzor 4x2, grafiki 106-113). Dowod, ze to skutek konwersji: oryginalna mapa 7.6 nie uzywa zadnego z tych 19 numerow ANI RAZU, a nasza uzywa ich 2921 razy i zawsze jako przedmiot na kafelku, nigdy jako grunt - wiec zadna prawdziwa woda z nich nie korzystala i przestawienie bylo bezpieczne. Kierunek kazdej sciany dobrany z ulozenia na mapie (490 ma 1025 sasiadow w pionie i 0 w poziomie -> grafika pionowa 4446; 627 ma 221 w poziomie -> pozioma 4445). Sprawdzone: liczba przedmiotow w items.otb bez zmian (12932), zmienionych dokladnie 19 wpisow, dlugosc pliku bez zmian, wszystkie numery w zakresie klienta. Po restarcie serwera kafelek 32092 wyglada jak szara kamienna sciana. Audyt calej mapy

Verdict: NAPRAWIONE i sprawdzone w grze. Dzwignie 60137 i 60138 na Rookgaard nie mialy zadnego skryptu - przyszly z mapa scalona z 8.6. Wzorem byl oryginalny skrypt z paczki 7.6 (data/actions/scripts/Nova carpeta/rook/sewer grate switch.lua), ktory dzialal na tym samym miejscu, tylko dzwignie mialy tam uid 3009 i 3010. Dodany skrypt data/actions/scripts/other/mostek-rookgaard.lua zamienia srodkowy kafelek mostu (32100,32205,8) miedzy deskami (5663) a woda (4622, BLOCK_SOLID), a dwa skrajne kafelki zostaja pomostem jako podejscia. Obie dzwignie dzialaja i przestawiaja sie razem. Most nie schowa sie, gdy ktos na nim stoi.

Verdict: Woda ciagnela sie wzdluz sciany serverid 490 obok kafelka gracza. NAPRAWIONE i OBEJRZANE W GRZE. Przyczyna byla w moscie serverid -> clientid w items.otb, nie w grafikach. Mapa przyszla z 8.6 i przy konwersji te przedmioty dopasowano po grafice do numerow 7.6, ktore sa WODA: serverid 490 "wall" wskazywal clientid 618, a 618 to w kliencie 7.6 animowana woda (16 klatek, wzor 4x2, grafiki 106-113). Dowod, ze to skutek konwersji: oryginalna mapa 7.6 nie uzywa zadnego z tych 19 numerow ANI RAZU, a nasza uzywa ich 2921 razy i zawsze jako przedmiot na kafelku, nigdy jako grunt - wiec zadna prawdziwa woda z nich nie korzystala i przestawienie bylo bezpieczne. Kierunek kazdej sciany dobrany z ulozenia na mapie (490 ma 1025 sasiadow w pionie i 0 w poziomie -> grafika pionowa 4446; 627 ma 221 w poziomie -> pozioma 4445). Sprawdzone: liczba przedmiotow w items.otb bez zmian (12932), zmienionych dokladnie 19 wpisow, dlugosc pliku bez zmian, wszystkie numery w zakresie klienta. Po restarcie serwera