Manawydan Mantis - Manawydan klient
Detaily problému
IDProjektKategorieZobrazit stavDatum vloženíPoslední změna
0001050Manawydan klientChybyveřejný30.12.2012 - 00:1004.03.2013 - 09:45
ReportérStig 
PřiřazenGeo 
PrioritanormálníZávažnostmaláReprodukovatelnostnevyzkoušeno
StavvyřešenýŘešeníotevřený 
PlatformaOSVerze OS
Verze produktu 
Cílová verzeVyřešeno ve verzi 
Shrnutí0001050: Obarvování itemů s partial hue
PopisFiddler i InsideUO exportuje ze hry plate chest s vadnyma pixelama (nekde neni R=G=B tam kde "ma byt") ale pritom kdyz to ve hre obarvim tak to v gumpu obarvi i ty pixely co "by nemelo". Pritom tooltip co vyjizdi uz je "spravne" zobrazuje vadny, neobarveny. Nejlepe je to patrne prave na plate chest, kde je videt, ze v gumpu se obarvi i to, kde R != G != B (nektere pixely na kovovych castech plate chest), zatimco v tooltipu ne.. a naopak - v gumpu jsou obarvene i hnede pasky kde R != G != B (tedy obarvene by byt nemely) a v tooltipu jsou tyto pasky spravne videt neobarvene, v puvodni hnede barve. Tedy gump neco obarvuje tak jak by to melo idealne vypadat a tooltip take, ale kazda z tech verzi obsahuje chyby (ani jedno zobrazeni neni bezchybne u plate chest).. bohuzel se mi vsak nepodarilo odhalit v tom zadnou zakonitost.
Pripojil sem screenshot kde je to dobre patrne, jinak se to musi pixel po pixelu prochazet v grafickym editoru a hledat..

PS: Ty obrazky exportovany skrz Fiddlera a InsideUO obsahuji technicky "vadne" pixely (R != G != B), pokud mam spravne informace. Je to "original" grafika. Je to u vice itemu (treba jeste roby). Divny je, ze gump si s tim poradi a tooltip ne. A gump si zas neporadi s NEobarvenim kozenych casti (R != G != B).
Postup na reprodukci problému
Další informace
ZnačkyŽádné štítky nepřiloženy.
Závislosti
Přiložené soubory? tooltip_gump.BMP (563,888) 30.12.2012 - 00:13
http://mantis.manawydan.cz/file_download.php?file_id=96&type=bug
png plate.png (5,338) 03.01.2013 - 08:22
http://mantis.manawydan.cz/file_download.php?file_id=97&type=bug
png
Historie problému
Čas modifikaceUživatelské jménoPoleZměna
30.12.2012 - 00:10StigNový problém
30.12.2012 - 00:13StigPřidán soubor: tooltip_gump.BMP
30.12.2012 - 02:10StigPopis upravenbug_revision_view_page.php?rev_id=714#r714
30.12.2012 - 02:13StigPopis upravenbug_revision_view_page.php?rev_id=715#r715
30.12.2012 - 02:17StigPopis upravenbug_revision_view_page.php?rev_id=716#r716
30.12.2012 - 02:18StigPopis upravenbug_revision_view_page.php?rev_id=717#r717
30.12.2012 - 12:39GeoPoznámka přidána: 0002612
30.12.2012 - 12:40GeoPřiřazen => Geo
30.12.2012 - 12:40GeoStavnový => přiřazený
30.12.2012 - 14:35StigPoznámka přidána: 0002617
30.12.2012 - 14:36StigPoznámka upravena: 0002617bug_revision_view_page.php?bugnote_id=2617#r719
03.01.2013 - 08:21Geo"Sticky" problémNe => Ano
03.01.2013 - 08:21Geo"Sticky" problémAno => Ne
03.01.2013 - 08:22GeoPřidán soubor: plate.png
03.01.2013 - 08:26GeoPoznámka přidána: 0002646
03.01.2013 - 08:27GeoPoznámka upravena: 0002646bug_revision_view_page.php?bugnote_id=2646#r723
04.01.2013 - 02:33StigPoznámka přidána: 0002652
04.01.2013 - 10:49GeoPoznámka přidána: 0002653
04.01.2013 - 10:49GeoPoznámka upravena: 0002653bug_revision_view_page.php?bugnote_id=2653#r725
04.03.2013 - 09:45GeoPoznámka přidána: 0002812
04.03.2013 - 09:45GeoStavpřiřazený => vyřešený
04.03.2013 - 09:45GeoPoznámka upravena: 0002812bug_revision_view_page.php?bugnote_id=2812#r781

Poznámky k problému
(0002612)
Geo   
30.12.2012 - 12:39   
Hodilo by se zadat správné chování.
(0002617)
Stig   
30.12.2012 - 14:35   
(upraveno: 30.12.2012 - 14:36)
Formalne spravne chovani je kombinaci obou pozorovanych vykreslovani.

Pixely, kde R != G != B se pri obarveni neobarvuji.
Pixely, kde R = G = B (stupne sedi) se pri obarveni obarvuji.

Otazka je, jestl nam jde o "spravne" (formalne) vykreslovani za kazdou cenu, nebo o funkcnost. To vyse popsane by treba tu Plate chest zobrazovalo proste osklive.. Plate chest a jeji "vadne" pixely mozna nevykresluje gump formalne "spravne", ale vykresluje je zadoucim zpusobem.
Idealni by asi bylo analyzovat, jak obe rozhrani vykresluji ty obarvene pixely v zavislosti na jejich puvodnim RGB. Cast vykreslovani by se zkratka pouzila z gumpu (ta cast, co zvladne u PlateChest, Robe atd. nejakym zazrakem obarvit i vadne pixely) a cast vykreslovani by se pouzila z tooltipu (ta cast, co zvladne u PlateChest, Robe atd. NEobarvit pixely, kde RGB nejsou stejne hodnoty).

Bohuzel, vic asi nepomohu.. Jen si rikam, ze by se to mohlo brzy hodit az bude system materialu - prostym obarvenim bysme dostali zbran/zbroj z jineho kovu, zadne nove itemy. Nevim, co s tim, ale kdyztak muzu pomoct kdyby bylo potreba upravovat nejaky grafiky (ty chyby asi ale budou u spousty itemu, takze opravit vsechno ciste graficky neni jen tak).
(0002646)
Geo   
03.01.2013 - 08:26   
(upraveno: 03.01.2013 - 08:27)
Koukni na plate.png.
Toho jsem docílil pouhým rozšířením podmínky na Math.Abs(R-B)<=1 && Math.Abs(B-G)<=1
... prostě když se liší pouze o 1.

Myslím si, že to tam mohu takhle nechat a rozlišovat Full a Partial pouze podle zadání barvy (0x8000 + barva = full).

Co vy na to?

P.S. samozřejmě by to tak vypadalo na postavě, v paperdollu, v batohu i v tooltipu
(0002652)
Stig   
04.01.2013 - 02:33   
To vypada dobre, snad to zadnou grafiku nerozhodi, ale holt to musime zkusit..
(0002653)
Geo   
04.01.2013 - 10:49   
Takhle, nešla by obarvit např. jelení čapka, kožené brnění... pokud bych neumožnil v čísle barvy specifikovat "full coloring", což chci.
(0002812)
Geo   
04.03.2013 - 09:45   
Jeden se neustále učí, možnost obarvovat předměty pomocí full/partial už je, takže do toho zasahovat nebudu (informace se bere pro konkrétní itemid z ItemData (ať už to znamená cokoliv).

Takže jsem odhalil chybu (rozdílný přístup v rozhodování o barvě u předmětů ve hře, na paperdollu a v tooltipu) a přístup sjednotil podle paperdollu.

(bude ve verzi 2013.03)