[8.42/8.5+][C++] doPlayerAddExhaust

Jak wiemy, exhausted jest bardzo ważną rzeczą na OTS.
Cóż, funkcja dająca exhausted była mi bardzo potrzebna, więc ją sobie napisałem i postanowiłem się nią podzielić.

Jest ona bardzo prosta:

luascript.cpp
Szukamy:

Kod:

---

        //doPlayerAddSkillTry(cid, skillid, n)
        lua_register(m_luaState, "doPlayerAddSkillTry", LuaScriptInterface::luaDoPlayerAddSkillTry);

---

Pod tym dodajemy:

Kod:

---

        //doPlayerAddExhaust(cid, exhaust)
        lua_register(m_luaState, "doPlayerAddExhaust", LuaScriptInterface::luaDoPlayerAddExhaust);

---

Szukamy:

Kod:

---

int32_t LuaScriptInterface::luaDoPlayerAddSkillTry(lua_State* L)

---

Pod tym dodajemy (jako nową funkcję):

Kod:

---

int32_t LuaScriptInterface::luaDoPlayerAddExhaust(lua_State* L)
{
        //doPlayerAddExhaust(uid, type, exhaust)
        uint32_t exhaust = popNumber(L), type = popNumber(L);

        ScriptEnviroment* env = getScriptEnv();
        if(Player* player = env->getPlayerByUID(popNumber(L)))
        {
                player->addExhaust(exhaust, type);
                lua_pushboolean(L, LUA_NO_ERROR);
        }
        else
        {
                reportErrorFunc(getErrorDesc(LUA_ERROR_PLAYER_NOT_FOUND));
                lua_pushboolean(L, LUA_ERROR);
        }
        return 1;
}

---

luascript.h
Szukamy:

Kod:

---

static int32_t luaDoPlayerAddSkillTry(lua_State* L);

---

Pod tym dodajemy:

Kod:

---

static int32_t luaDoPlayerAddExhaust(lua_State* L);

---

Testowane na TFS 0.3 pod 8.42.

Używamy pisząc:
doPlayerAddExhaust(uid, A, B)
Gdzie:
uid - gracz docelowy
A - rodzaj exhausted:
1 - na czary agresywne
2 - na czary nieagresywne
itd.
B - czas, długość exhausted

A przypadkiem exhausted nie jest jednym z conditionów i nie jest dodawane przez doPlayerAddCondition? Przynajmniej za czasów jak interesowałem się OTSami najnowsze OTSy tak właśnie miały to rozwiązane...

Pozdrawiam
Killavus

Zgadza się Killa, exhausted obsługiwane jest przez conditions, więc ten kod to tylko niepotrzebny zapychacz silnika

Cytuj:

---

Killavus napisał

A przypadkiem exhausted nie jest jednym z conditionów i nie jest dodawane przez doPlayerAddCondition? Przynajmniej za czasów jak interesowałem się OTSami najnowsze OTSy tak właśnie miały to rozwiązane...

Pozdrawiam
Killavus

---

Cytuj:

---

Tairens napisał

Zgadza się Killa, exhausted obsługiwane jest przez conditions, więc ten kod to tylko niepotrzebny zapychacz silnika

---

Owszem, z tym, że zastosowałem prosty skrypt z pętlą, gdzie w zasięgu gracza pobierał wszystkie jednostki (graczy) i dawał im exhausted - nie zadziałało. Hadorek osobiście widział, bo testowałem ten czar dla niego. Dla testu wywaliłem z pętli i dałem tylko cidowi - zadziałało. To sprawdziłem, czy prawidłowo pobiera istoty - prawidłowo (ustawiłem, żeby cidowi wyświetlał getCreatureName, jeśli trafi na gracza). W związku z tym condition po prostu jest jakiś zepsuty w pętli...

Natomiast, gdy zastosowałem moją funkcję - zadziałało przy pętli.

Oto dwa przykłady:

Kod:

---

local condition = createConditionObject(CONDITION_EXHAUST)
setConditionParam(condition, CONDITION_PARAM_TICKS, 50000)

function onSay(cid, words, param, channel)
        local xx
        local yy
       
        for xx = getCreaturePos(cid).x - 4, getCreaturePos(cid).x + 4 do
                for yy = getCreaturePos(cid).y - 4, getCreaturePos(cid).y + 4 do
                        local poss = {x = xx, y = yy, z = getCreaturePos(cid).z, stackpos = 253}
                        local gracz = getThingFromPos(poss)
                        doSendMagicEffect(poss,1)
                        if isPlayer(gracz.uid) then
                                doSendMagicEffect(poss,3)
                                doPlayerSendTextMessage(cid,22,getCreatureName(gracz.uid))
                                doAddCondition(gracz.uid,condition)
                        end
                end
        end
end

---

Kod:

---

function onSay(cid, words, param, channel)
        local xx
        local yy
       
        for xx = getCreaturePos(cid).x - 4, getCreaturePos(cid).x + 4 do
                for yy = getCreaturePos(cid).y - 4, getCreaturePos(cid).y + 4 do
                        local poss = {x = xx, y = yy, z = getCreaturePos(cid).z, stackpos = 253}
                        local gracz = getThingFromPos(poss)
                        doSendMagicEffect(poss,1)
                        if isPlayer(gracz.uid) then
                                doSendMagicEffect(poss,3)
                                doPlayerSendTextMessage(cid,22,getCreatureName(gracz.uid))
                                doPlayerAddExhaust(gracz.uid, 1, 15000)
                        end
                end
        end
end

---

Nie jest przypadkiem tak, że w momencie nałożenia conditiona obiekt ten nie jest na 'twardo' łączony z danym UID?

Pozdrawiam
Killavus

Cytuj:

---

Killavus napisał

Nie jest przypadkiem tak, że w momencie nałożenia conditiona obiekt ten nie jest na 'twardo' łączony z danym UID?

Pozdrawiam
Killavus

---

Czyli musiałbym zastosować 16 conditionów?

Mmmmm...

Kod:

---

exhaustion.set(cid, storage, czas)

---

Kod:

---

exhaustion.check(cid, storage)

---

w 0.3.4pl2 wystarczy zlinkować to w data.lua (w nowszych tfs'ach jest już domyślnie włączone)

Kod:

---

dofile(getDataDir() .. "lib/exhaustion.lua")

---

Cytuj:

---

Zloom napisał

Mmmmm...

Kod:

---

exhaustion.set(cid, storage, czas)

---

Kod:

---

exhaustion.check(cid, storage)

---

w 0.3.4pl2 wystarczy zlinkować to w data.lua (w nowszych tfs'ach jest już domyślnie włączone)

Kod:

---

dofile(getDataDir() .. "lib/exhaustion.lua")

---

---

To jest 'własny' exhausted na cokolwiek, co zechcesz. Nie można go połączyć z czarami, potionami itd. No, chyba, że im też dasz ten zamiast domyślnego.

#edit

Cytuj:

---

Elf napisał

Nah, conditions are possible just on load, that's why this has own use. Anyway, I've made possible to use conditions runtime, not just on load :P Check out 0.4

---

Condition można nadać jednej istocie, graczowi, jak chcesz objąć X graczy, musisz dać X conditionów, a to jest strata wydajności. Ta funkcja to ułatwia, mogżna dać jedną, która może objąć wszystkich graczy na serwerze. Przyda się.

Thx Radeg again :D

Cytuj:

---

Blady3D napisał

Condition można nadać jednej istocie, graczowi, jak chcesz objąć X graczy, musisz dać X conditionów, a to jest strata wydajności. Ta funkcja to ułatwia, mogżna dać jedną, która może objąć wszystkich graczy na serwerze. Przyda się.

Thx Radeg again :D

---

Pragę dodać, że to nie tylko strata wydajności, ale i bezsensowna strata miejsca w skrypcie. Kto by wolał pisać 50 conditionów dla 50 osób, skoro można wrzucić ten kod i dać po prostu w pętli.
A i dziękuję za pozytywny komentarz kogoś, kto coś wie na ten temat, a nie na przykład:

Cytuj:

---

Tairens napisał

Zgadza się Killa, exhausted obsługiwane jest przez conditions, więc ten kod to tylko niepotrzebny zapychacz silnika

---

Chyba już się sprzeczamy po raz drugi i znów wyszedłeś na buraka, co?

Burakiem nadal jesteś Ty, tworząc bzdurne funkcje i próbując ukazać jakiego to nie masz skilla w c++.

Cytuj:

---

Tairens napisał

Burakiem nadal jesteś Ty, tworząc bzdurne funkcje i próbując ukazać jakiego to nie masz skilla w c++.

---

No, ciekawe masz argumenty...
Jeśli dla ciebie prosty luascript jest pokazaniem skilla to już widzę twój poziom wiedzy.

Cytuj:

---

Grim90 napisał

Pragę dodać, że to nie tylko strata wydajności, ale i bezsensowna strata miejsca w skrypcie. Kto by wolał pisać 50 conditionów dla 50 osób, skoro można wrzucić ten kod i dać po prostu w pętli.
A i dziękuję za pozytywny komentarz kogoś, kto coś wie na ten temat, a nie na przykład:

---

Tak swoją drogą, to nie żadna strata wydajności - bądź co bądź i tak obiekt Condition jest tworzony przy dodawaniu exhausted, tylko niejawnie - wewnątrz implementacji funkcji addExhaust. Więc argument o zwiększeniu wydajności jest co najmniej dyskusyjny - Lua jest bardzo szybkim językiem (jak na języki interpretowane), a tworzenie obiektów jawnie nie jest wcale takie powolne... Zresztą, cóż to za strata miejsca w skrypcie - skoro już używasz pętli, dlaczego nie możesz użyć tablicy, bądź lepiej - tworzyć chwilowe obiekty Condition i łączyć je z aktualnym 'celem'?

Stąd też naskoczenie na Tairensa, a raczej jego cel jest... hm, bezcelowe i niepoparte żadnymi racjonalnymi argumentami?

Pozdrawiam
Killavus

Cytuj:

---

Killavus napisał

Tak swoją drogą, to nie żadna strata wydajności - bądź co bądź i tak obiekt Condition jest tworzony przy dodawaniu exhausted, tylko niejawnie - wewnątrz implementacji funkcji addExhaust. Więc argument o zwiększeniu wydajności jest co najmniej dyskusyjny - Lua jest bardzo szybkim językiem (jak na języki interpretowane), a tworzenie obiektów jawnie nie jest wcale takie powolne... Zresztą, cóż to za strata miejsca w skrypcie - skoro już używasz pętli, dlaczego nie możesz użyć tablicy, bądź lepiej - tworzyć chwilowe obiekty Condition i łączyć je z aktualnym 'celem'?

Stąd też naskoczenie na Tairensa, a raczej jego cel jest... hm, bezcelowe i niepoparte żadnymi racjonalnymi argumentami?

Pozdrawiam
Killavus

---

Co do wydajności - nie będę się kłócił, zapewne masz rację.
Oczywiście, że można wrzucić pięknie w tablicę i za pomocą pętli wszystko ciachnąć.

Co do condition: nie można wrzucić condition do środka skryptu. Musi on być PRZED nim. Dokładnie pojawia się taki błąd:

Cytuj:

---

Serwer napisał

Lua Script Error: [TalkAction Interface]
data/talkactions/scripts/test.lua:onSay

luaCreateConditionObject(). This function can only be used while loading the script.

Lua Script Error: [TalkAction Interface]
data/talkactions/scripts/test.lua:onSay

luaSetConditionParam(). This function can only be used while loading the script.

---

Zatem muszę twardo podać, ile conditionów ma być, oraz podać ich atrybuty. Przykładowo, jeśli nie wiem, ile będę musiał ich użyć, to co wtedy zrobić? Ja u siebie znalazłem rozwiązanie i użyłem luascriptu, który jest elastyczniejszy.

Cytuj:

---

Grim90 napisał

Co do wydajności - nie będę się kłócił, zapewne masz rację.
Oczywiście, że można wrzucić pięknie w tablicę i za pomocą pętli wszystko ciachnąć.

Co do condition: nie można wrzucić condition do środka skryptu. Musi on być PRZED nim. Dokładnie pojawia się taki błąd:


Zatem muszę twardo podać, ile conditionów ma być, oraz podać ich atrybuty. Przykładowo, jeśli nie wiem, ile będę musiał ich użyć, to co wtedy zrobić? Ja u siebie znalazłem rozwiązanie i użyłem luascriptu, który jest elastyczniejszy.

---

Ja bym po prostu zainicjalizował tyle conditionów ile mi maksymalnie potrzebne - chyba nie jest trudno policzyć?

Swoją drogą, chyba ograniczenie tworzenia obiektów condition do etapu ładowania skryptu do czegoś służyło, więc obchodzenie tego w ten sposób może prowadzić do niebezpieczeństwa niestabilności (zapewne).

Pozdrawiam
Killavus

Cytuj:

---

Killavus napisał

Ja bym po prostu zainicjalizował tyle conditionów ile mi maksymalnie potrzebne - chyba nie jest trudno policzyć?

Swoją drogą, chyba ograniczenie tworzenia obiektów condition do etapu ładowania skryptu do czegoś służyło, więc obchodzenie tego w ten sposób może prowadzić do niebezpieczeństwa niestabilności (zapewne).

Pozdrawiam
Killavus

---

W tym przypadku zastanawiam się, czy faktycznie lepiej (wydajniej) walnąć tyle conditionów, ile jest mi potrzebne, czy po prostu dać prostą pętlę i skorzystać mojej funkcji.
Przykładowo, weźmy pod uwagę taką możliwość, że robię duży quest i w pewnym jego momencie gracze dochodzą do areny o rozmiarze 30x30 kratek, jest ona tak duża ze względu, dajmy na to, późniejszego pojawienia się dużej ilości potworów na niej.

Chciałbym nadać exhausted wszystkim graczom na niej na dłuższy czas. Oczywiście jest to tylko przykład, co mówię. Zakładam, że graczy będzie mniej, niż rozmiar areny, ale jest ona duża, mogą stać gdziekolwiek na niej, wówczas 30x30 = 900(!) conditionów musiałbym zarzucić. Dla kogo, jak dla kogo, ale dla mnie o wiele czytelniejsze byłoby nadanie zwykłej pętli, która przeskanuje arenę, da każdemu exhausted, o ile tam znajduje się gracz i już.

Co do niestabilności, raczej chyba nie :P Elf napisał, że w nowym TFS można będzie dać condition z poziomu skryptu. Wiem, to jest 0.4 a ten, co mam to 0.3. Robiłem testy z kilkoma znajomymi i żadnych komplikacji nie było (czego nie mogę powiedzieć o condition) :P

Cytowałem go wcześniej już.

Cytuj:

---

Elf napisał

Nah, conditions are possible just on load, that's why this has own use. Anyway, I've made possible to use conditions runtime, not just on load :P Check out 0.4

---

O, właśnie zrobiłem malutki test :P
Dokładnie na tej arenie umieściłem kilkunastu graczy (komp mi już zamula ostro) i w pętli każdy dostał exhausted. Działa.

Dawno nie siedziałem w OTS'ach, więc pewnie palnę głupotę. Ale spelle obszarowe chyba mogą założyć kilka conditionów w prosty sposób za 1 razem?