Bug Reports

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: 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: 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: 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: 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: 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.