Hej, moge to sobie zabrac i zrobic?
A jesli tak, to moge poprosic o jakies przyklady uzycia tej funkcjonalnosci? (z punktu widzenia programisty, nie z punktu widzenia gracza)

A pewnie, bierz.
- funkcja Bleed w aktorze może zostawiać ślady krwi
- w momencie eksplozji może się pojawiać animacja eksplozji w odpowiednim miejscu (w ramach etParticleEffect)
- w czasie rzucania czaru w ramach cast-time-effect w CAbilityPerformerze można dodać animację rzucania tegoż czaru (jakaś formująca się ognista kula) z odpowiednim przesunięciem względem aktora
- analogicznie można dodać animację "uderzenia", gdy gracz jest trafiony ciosem wręcz np. od ogra

dobra, zobacze na dniach co tam da sie zrobic :)

Jeszcze dwie prośby:
- jakbyś był wstanie to podpiąć pod wspólny interfejs z aktualnymi efektami graficznymi (gGraphicalEffects.ShowEffect) to by znacznie ułatwiło wykorzystanie z różnych miejsc w kodzie
- jakbyś był w stanie zrobić wywołanie "od physicala do physicala" i "od physicala do x,y" (przypadek użycia: rzucanie błyskawicy)... ale to może być zupełnie oddzielna kwestia... i specjalnie realizowane

dałoby radę? byłby komplet funkcjonalności :)

o, nie zauwazylem, ze cos tu pisales - szkoda, ze po dodaniu nowego komentarza ticket nie przechodzi w jakis stan pt "musisz kliknac ponownie accept"

pierwsza prosba - z tego co patrzylem w kod, to chyba dam rade (na jakie przeszkody sie jednak natkne po drodze to nie wiem - bede dopytywac sie podczas prania)

natomiast z tym drugim - jak to ma dzialac? jak to sobie wyobrazasz z punktu widzenia na ekranie, oraz z punktu widzenia kodu/metody - jaka sie bedzie w tym celu wywolywac?

cos w rodzaju gGraphicasEffects.ShowEffect( "blyskawica", odPhysical, doPhysical ) i w takim przypadku ma sie obrazek.png w ciagu powiedzmy polsekundy przesuwac od pozycji odPhysicala do pozycji doPhysicala i tamze zniknac? bez zadnych cyrkow z rozciaganiem tego obrazka? czy tez moze wlasnie to ma byc natychmiastowy 'beam' (czyli nie wiem, obrazek.png odpowiednio rozciagniety i obrocony) pokazujacy sie od pozycji odPhysicala do pozycji doPhysicala i po ulamku sekundy znikajacy?

podrzucilbys jakies wskazowki?

(b) - myślałem o czymś takim: http://i.thottbot.com/ss/o/35327.jpg - taka zygzagująca, zmienna błyskawica pozostająca widoczna przez jakąś sekundę... wiem, że to trudne :) Jak pisałem "to może być zupełnie oddzielna kwestia… i specjalnie realizowane" to właśnie miałem na myśli, że być może opracowanie interfejsu wystarczy. + może jakiś stub...? żeby cokolwiek się wyświetliło... kurde, sam nie wiem :) Jeśli miałbym wybierać z tych dwóch propozycji co napisałeś powyżej, to lepiej będzie wyglądać wariant "przesuwający". Z drugiej strony, jeśli odpowiednio dobrać grafikę, można rozciągnięciem uzyskać brzydki wariant tego: http://dota-autoscript.com/img/guide/lion/lionimpalemanadrain.png ...

Zrób jak uważasz, to i tak tylko skomplikowany bajer. gGraphicsEffects.ShowEffect( "blyskawica", odPhysical, doPhysical ) to dla mnie wystarczający interfejs :)

Zdecydowanie zapre sie nogami przed robieniem takich blyskawic jak te zaprezentowane na linkach (bardzo dobre ilustracje! dobrze wyjasniaja co masz na mysli!).

Umowmy sie zatem, ze owszem, zrobie zaslepke typu:
gGraphicsEffects.ShowEffect( "blyskawica", odPhysical, doPhysical );

i ze ta zaslepka bedzie pokazywac jakis zaslepkowy efekt (ja podejme ostateczna decyzje, jak ten zaslepkowy efekt bedzie wygladac), ale pelnej realizacji blyskawic ja sie nie podejme.

Related association with ticket #187 was added

Acknowledged :) zróbmy z tego oddzielny ticket w takim razie, może ktoś będzie miał ochotę.

Related association with ticket #191 was added

odsuwam w czasie

masz jakieś plany na xml-izację ?

tuz po tym jak zawładnę swiatem

notka do siebie - do zrobienia pozostalo(?) dorobic wczytywanie epsow (tych preparowanych) z jakiegos xml'a do mapy string->eps

przenosze na blizej nieokreslona przyszlosc - to nie(?) jest potrzebne do wypuszczenia releasu 30sierpnia

Do zrobienia tutaj w tym tickecie zostala deserializacja parametrow efektow graficznych z pliku do CGraphicalEffect (zeby sobie przy inicjalizacji ladnie czytal z pliku wszystkie ustawienia animacji, particli, kolorkow itp itd)

Ale ja tak patrze i uwazam, ze to jest niepotrzebne - do tej pory wrzucalismy nowe efekty z palca bezposrednio do kodu i raczej krzywda sie nikomu nie dziala. Natomiast ja bym sie zaparl przed pisaniem deserializatora, bo tam w CGraphicalEffects sa takie kwiatki jak np:

eps.image = "data/effects/magic/magiccircle" + StringUtils::ToString( gRand.Rnd( 1, 5 + 1 ) ) + ".png"
eps.zIndex = Z_BLOOD_SPLATS - 1;
eps.rotation = gRand.Rndf( 0, 360 );

i jak sobie pomysle o parsowaniu takich konstrukcji tylko po to, zeby... no wlasnie, zeby co? Zeby miec osobno kod , a osobno dane? Zeby kolejne efekty korzystajace z podobnych hakow wymuszaly rozbudowywanie parsera? To dochodze do wniosku, ze to nie jest warte machania łapą.

Co Ty sadzisz o tej sprawie?

cóż, zdecydowanie nie jest to priorytet - aktualny wariant działa, jak będzie potrzeba zrobić to przez XMLe to mogę poświęcić wieczór i to zrobić. Czym mogłaby być taka potrzeba powodowana...? A bo ja wiem, włączeniem nie-programisty do projektu jako twórcy contentu? Kogoś pracującego na zasadzie moddera... ? Pomysł niby fajny, wydawałoby się że może działać, ale na razie na to jest kompletny brak perspektyw (nie tylko nie ma chętnych, ale też inne rzeczy bardziej blokują). Proponuję odwiesić ten ticket z priority Lowest, niech sobie ta dyskusja tu poleży, a robić tego nie ma co.

a tak technicznie - tam coś będzie oprócz randomów ? Takich
eps.animation = "core/anim/effects/blue-explosions/" + StringUtils::ToString( gRand.Rnd( 1, 16 + 1 ) );
są na pęczki, ale czy mamy jakiś powód by tam się spodziewać innej logiki niż "wybierz losowy obrazek" lub "wybierz losową animację"?

No, juz ja widze jak ten nie-programista z ochota i werwą zabiera sie za grzebanie w xmlach i cos pozytecznego wytwarza.

"a tak technicznie":
Cholera wie. Tak naprawde to wiekszosc tych efektow graficznych (jesli nie calosc) powinna byc realizowana przez particle. Tak, zeby to particle affectory grzecznie zarzadzaly tym calym obracaniem, zanikaniem, powiekszaniem itp itd. A wracajac do pytania: nie jestem w stanie wyobrazic sobie, co takiego w przyszlosci mogloby sie znalezc oprocz randomow.

Lap buga - ja go nie chce spowrotem -> i tak sie nim dzisiaj/na dniach nie zajme.

Child association with ticket #365 was added

niech ktoś inny się tym zajmie (albo nie)

na mocy #753 - albo ktos sie tym zajmie i zaassignuje na siebie, albo wontfixuje za tydzien

Updating tickets (#368, #370, #420, #529, #570, #578, #592, #609, #610, #613, #619, #627, #629, #636, #637, #663, #664, #699, #710, #732, #734, #738, #742, #744, #747, #411, #616, #634, #638, #661, #668, #697, #698, #719, #735, #168, #282, #340, #355, #365, #371, #383, #561, #642, #665, #700)

wontfix