Než se rozepíšu, tak předesílám, že se zmíněným systémem na WoW nemám zkušenosti a je škoda, že jeho koncepty autor tématu více nepřiblížil. Návrh zřejmě staví na existenci nějakého
API pro klienta Ekury, které zahrnuje minimálně:
- nějaké množství předdefinovaných akcí, které lze upravit (např. "OnChatTextRender", "OnAppStart", ...)
- seznam hodnot, které lze uživatelsky měnit a k nim příslušných metod (např. "SetTextSize", "SetSkyColorVector", ...)
- samozřejmě také seznam metod, kterými lze současnou hodnotu načíst z paměti, něbo z nastavení hry (např. "GetTextColor", "GetDefaultTextColor", ...)
- podporu nějakého skriptovacího jazyka (nejlépe Pythonu, který už v klientovi běží), ve kterém lze snadno provádět matematické operace, ukládat hodnoty do různých datových struktur ap., přičemž vývojář takového "Add-inu" by musel docela určitě mít přístup také k debugovací konzoli hry
- nějaký způsob logického uspořádání akcí tak, aby si v případě aktivace více "Add-inů" tyto vzájemně nepřepisovaly hodnoty, které oba mění
- možnost uložení interní konfigurace modulu do nějakého souboru a opětovné načtení plus možnost přidat také další data (například obrázky, kurzory, ...) do balíčku s "Add-inem" a umožnit k nim jednoduchý a rychlý přístup
- kompletní, nebo téměř kompletní dokumentaci (protože bez ní se tvůrci "Add-inů" moc daleko nedostanou)
Takové API ale Ekura nemá. Není těžké si ho představit, ale určitě by bylo velmi časově náročné jej na slušné úrovni naprogramovat - a to mluvím pouze o základním systému. Následně by pro každou akce, kterou by si tvůrci "Add-inů" přáli změnit, bylo potřeba ručně doprogramovat příslušné metody, nebo alespoň zrevidovat parametry těch existujících, aby bylo jejich použití intuitivní a předešlo se možnosti zneužití. Tomu bude s rozšiřujícím se systémem čím dál tím složitější zabránit a (nejen) proto by nebylo od věci, aby každý uveřejněný "Add-in" prošel nějakým schvalovacím řízením a zběžnou kontrolou kódu. Kolik akcí by vlastně mělo být ze strany API podporováno? Jsou to řádově desítky, stovky, nebo tisíce? Návrh je v tomhle ohledu hodně nedotažený.
Pojďme ale ke konkrétním příkladům:
Obchodnik799 píše: ↑sob 14. črc 2018 19:58:08Barvy textu a velikosti
V současné době jich hra používá jen několik. Pokud bychom chtěli, aby šly měnit nezávisle na sobě, musel by se tomu výrazně uzpůsobit systém. A protože se může stát, že nebude některá z hodnot definovaná, musel by systém po vykreslení každého okna (nebo jiné minimální jednotky) nastavení fontu vyresetovat na nějaké výchozí.
Obchodnik799 píše: ↑sob 14. črc 2018 19:58:08Sloučení 1 a 2 inventu, do vetsiho pole
Je v podstatě o přepsání celého kódu inventáře. Bylo by potřeba umožnit kompletní přístup ke všem prvkům v inventáři - jejich velikosti, pozice a zarovnání, pozadí, viditelnost, stavy, flagy, nabindované akce. Pro zajímavost: třída, který obsluhuje fungování inventáře má momentálně 2100 řádků. V tomhle počtu ještě chybí různé interakce inventáře s jinými okny, takže výsledné číslo bude ještě vyšší. Pokud bychom chtěli dát autorům "Add-inů" absolutní volnost v uspořádání takového okna, musela by být téměř každá metoda ve zmíněné třídě nějakým způsobem modulární a zdokumentovaná.
Obchodnik799 píše: ↑sob 14. črc 2018 19:58:08ctrl+i by prepipalo mezi nazvama a popiskama
Je z téhle trojice asi nejjednodušší. I tak zahrnuje minimálně zpřístupnění možnosti odchytávat všechny klávesy, které hráč stiskne, a k některým nabindovat uživatelské akce. To, že nic takového ve hře momentálně není, je zároveň největší překážkou pro vytvoření konfigurovatelných klávesových zkratek přímo v nastavení hry.
Vliv na výkon
Někomu to už teď připadá příliš složité? Pak jsem jeden z Vás. Ale je to ještě horší, když si uvědomíte, že spousty předdefinovaných akcí by musely mít nějaký standartizovaný způsob ukončení. Vezměme si například tvůrce "Add-inu", který by si nepřál zobrazovat hlášky typu "Obdržel jsi 123.456 Yangů". To znamená, že metoda, která se o to stará, by musela obsahovat příslušnou událost a zároveň také definovat, co vše se musí stát, pokud daná událost běh metody ukončí - tj. něco jako "bezpečné ukončení". To by při větším množství metod už mohlo mít celkem výrazný dopad na výkon klienta a to dokonce i v případě, kdy žádné "Add-iny" nebudou nainstalované (v případě opačném je ještě potřeba si přičíst výkonový dopad běhu kódu v chráněném režimu - tj. aby třeba syntaktická chyba v uživatelském kódu neměla dopad na vnitřní kód hry).
Je o to skutečně zájem ze strany vývojářů?
V neposlední řadě bych ještě zmínil, že komunita Ekury se svou velikostí s tou ve WoW určitě nedá srovnávat. To sice neznamená, že by zde touha po něčem podobném byla menší, ale rozhodně je zde méně lidí, schopných a ochotných (ano, je potřeba obojí) se do něčeho takového pouštět. Předpokládám-li správně, že Add-iny by byly zdarma, tak jen podotýkám, že jeho vývoj nikdy není úplně snadný a zdaleka nekončí vydním prvotní verze, protože:
- Jeho uživatelé neustále požadují více toho, či onoho
- Herní API se s vývojem hry nevyhnutelně mění, takže je třeba držet krok
Kolik znáte lidí ze svého okolí, kteří mají dostatek zkušeností, volného času a chuti, aby se o vývoj takového "Add-inu" starali? Já žádného a to se mezi programátory pohybuji.
Závěrem
Představa je to pěkná, to nepopírám. V současné situaci, kdy je v týmu jeden aktivní programátor, je ale hodně vzdálená realitě. Dokud se to výrazně nezlepší, budu hlasovat proti tomuto návrhu.