712 odpovědí na toto téma

[matejcik]

Pe_Bo napsal/a:
Po bližším zkoumání bylo zjištěno, že OnStop event je vyvolán i v případě, že Countdown časovač doběhl a je pomocí stop zastaven. To je v rozporu s chováním jiných zařízení i emulátoru, vyzkoušeno prakticky.

no, timery jsem teď celkem drsně překopal, takže příštích několik dní to zřejmě nebude fungovat vůbec ;e))
tohle co popisuješ ... mám to chápat tak, že když dáš zastavit neběžící timer, tak se nemá vyvolat OnStop? pokud ano, tak opraveno

Zjistil jsem ještě jednu věc - timer objekt neimplentuje Remaining property, což by měl, v emulátoru je opět přítomna (jestli je přítomna i jinde, nevím).

snad taky opraveno.

ale verze, ve které to je, je značně rozkopaná, takže nevím, kdy ji vydám...

[Pe_Bo]

matejcik napsal/a:

Pe_Bo napsal/a:
Po bližším zkoumání bylo zjištěno, že OnStop event je vyvolán i v případě, že Countdown časovač doběhl a je pomocí stop zastaven. To je v rozporu s chováním jiných zařízení i emulátoru, vyzkoušeno prakticky.

no, timery jsem teď celkem drsně překopal, takže příštích několik dní to zřejmě nebude fungovat vůbec ;e))
tohle co popisuješ ... mám to chápat tak, že když dáš zastavit neběžící timer, tak se nemá vyvolat OnStop? pokud ano, tak opraveno

Zjistil jsem ještě jednu věc - timer objekt neimplentuje Remaining property, což by měl, v emulátoru je opět přítomna (jestli je přítomna i jinde, nevím).

snad taky opraveno.

ale verze, ve které to je, je značně rozkopaná, takže nevím, kdy ji vydám...

Ano, je to tak. Neběžící (resp. doběhlý) timer nevyvolá OnStop event při volání stop.

V té O statecnem "Kacerovi" GC1KDBX byl udělán workaround, aby to nevadilo, ale každopádně je lepší, když to chování je konzistentní napříč playery.

V souvislosti s výše uvedeno keší jsem pozoroval ještě dva problémy:

- pokud přijde nějaká událost v době, kdy je obsluhována jiná (např. uživatel vejde do zóny a přitom je zobrazen nějaký dialog z jiné události), pak se OpenWIG chová podivně, jakoby se provedla ta druhá obsluha vnořeně do té první - v emulátoru mi to připadá, jakoby ta druhá tu první událost utla a obsluha nepokračovala.
Nemám to ale ještě důkladně ověřené, zkusím udělat nějakou demonstrační cartridge

- často jsou reakce OpenWIGu velmi zpomalené, např. reakce na výběr zóny trvá třeba i tři vteřiny (mám N73, což mi nepřipadá jako zastaralý telefon)

[matejcik]

Pe_Bo napsal/a:
V souvislosti s výše uvedeno keší jsem pozoroval ještě dva problémy:

- pokud přijde nějaká událost v době, kdy je obsluhována jiná (např. uživatel vejde do zóny a přitom je zobrazen nějaký dialog z jiné události), pak se OpenWIG chová podivně, jakoby se provedla ta druhá obsluha vnořeně do té první - v emulátoru mi to připadá, jakoby ta druhá tu první událost utla a obsluha nepokračovala.
Nemám to ale ještě důkladně ověřené, zkusím udělat nějakou demonstrační cartridge

to skoro určitě takhle není. ale je možné, že zrušení dialogu funguje nějak trošku jinak.
pokud uděláš testovací cartridge, bude to super

- často jsou reakce OpenWIGu velmi zpomalené, např. reakce na výběr zóny trvá třeba i tři vteřiny (mám N73, což mi nepřipadá jako zastaralý telefon)

jednak java na symbianech je pomalá
jednak seekování v souborech (načítání obrázků) je na symbianech taky pomalý. v nový verzi jsem to předělal a mělo by se konkrétně tohle dost zrychlit

[Pe_Bo]

matejcik napsal/a:

Pe_Bo napsal/a:
V souvislosti s výše uvedeno keší jsem pozoroval ještě dva problémy:

- pokud přijde nějaká událost v době, kdy je obsluhována jiná (např. uživatel vejde do zóny a přitom je zobrazen nějaký dialog z jiné události), pak se OpenWIG chová podivně, jakoby se provedla ta druhá obsluha vnořeně do té první - v emulátoru mi to připadá, jakoby ta druhá tu první událost utla a obsluha nepokračovala.
Nemám to ale ještě důkladně ověřené, zkusím udělat nějakou demonstrační cartridge

to skoro určitě takhle není. ale je možné, že zrušení dialogu funguje nějak trošku jinak.
pokud uděláš testovací cartridge, bude to super

tak jsem to zkoušel a našel jsem ten rozdíl v chování.
Řekněme, že mám dvě zóny, Zone1 a Zone2. Každá ze zón zobrazí messagebox (každá jiný, dále Msg1 a Msg2) při vstupu, přičemž Msg1 má navíc definovaný callback - skript provedený při stisku tlačítka.
Nyní vstoupím do Zone1 a zobrazí se Msg1. Nic nemačkám a vstoupím do Zone2:

- v emulátoru (a podle všeho i v jiných playerech) se zobrazí Msg2, přičemž callback pro Msg1 se NEPROVEDE a čeká se na tlačítko v Msg2

- v OpenWIG blikne Msg2, nečeká se na stisk tlačítka a PROVEDE se callback z Msg1

[matejcik]

Pe_Bo napsal/a:tak jsem to zkoušel a našel jsem ten rozdíl v chování.
Řekněme, že mám dvě zóny, Zone1 a Zone2. Každá ze zón zobrazí messagebox (každá jiný, dále Msg1 a Msg2) při vstupu, přičemž Msg1 má navíc definovaný callback - skript provedený při stisku tlačítka.
Nyní vstoupím do Zone1 a zobrazí se Msg1. Nic nemačkám a vstoupím do Zone2:

- v emulátoru (a podle všeho i v jiných playerech) se zobrazí Msg2, přičemž callback pro Msg1 se NEPROVEDE a čeká se na tlačítko v Msg2

- v OpenWIG blikne Msg2, nečeká se na stisk tlačítka a PROVEDE se callback z Msg1

no přesně takhle to ale popisují v tutorialu a všude ! :e)

ale pozor. z toho, že "blikne Msg2" hádám, že součástí callbacku je další messagebox, Msg3 ?
logika je následující:
1. na obrazovce visí Msg1
2. skript S vyvolá Msg2.
3. v tu chvíli je Msg1 přepsán Msg2, a do fronty volání se zařadí callback z Msg1
4. pak doběhne skript S, uvolní se VM lua, a vyvolá se callback z Msg1
5. callback vyvolá Msg3, který přepíše Msg2 (ten nemá žádný callback)

zkus prosímtě namísto messageboxu použít něco jiného, třeba změnit popisek předmětu. zajímalo by mě, jestli
a) emulátor ten callback z Msg1 nevyvolá vůbec (to je podle mě bug)
b) nebo ho vyvolá uprostřed skriptu S (to je dost pravděpodobné, když nad tím tak přemýšlím)
c) nebo ho vyvolá po skončení skriptu S, ale Msg2 se vyvolá teprve po provedení callbacku (což je představa, která mě děsí)

[Pe_Bo]

matejcik napsal/a:

Pe_Bo napsal/a:tak jsem to zkoušel a našel jsem ten rozdíl v chování.
Řekněme, že mám dvě zóny, Zone1 a Zone2. Každá ze zón zobrazí messagebox (každá jiný, dále Msg1 a Msg2) při vstupu, přičemž Msg1 má navíc definovaný callback - skript provedený při stisku tlačítka.
Nyní vstoupím do Zone1 a zobrazí se Msg1. Nic nemačkám a vstoupím do Zone2:

- v emulátoru (a podle všeho i v jiných playerech) se zobrazí Msg2, přičemž callback pro Msg1 se NEPROVEDE a čeká se na tlačítko v Msg2

- v OpenWIG blikne Msg2, nečeká se na stisk tlačítka a PROVEDE se callback z Msg1

no přesně takhle to ale popisují v tutorialu a všude ! :e)

ale pozor. z toho, že "blikne Msg2" hádám, že součástí callbacku je další messagebox, Msg3 ?
logika je následující:
1. na obrazovce visí Msg1
2. skript S vyvolá Msg2.
3. v tu chvíli je Msg1 přepsán Msg2, a do fronty volání se zařadí callback z Msg1
4. pak doběhne skript S, uvolní se VM lua, a vyvolá se callback z Msg1
5. callback vyvolá Msg3, který přepíše Msg2 (ten nemá žádný callback)

zkus prosímtě namísto messageboxu použít něco jiného, třeba změnit popisek předmětu. zajímalo by mě, jestli
a) emulátor ten callback z Msg1 nevyvolá vůbec (to je podle mě bug)
nebo ho vyvolá uprostřed skriptu S (to je dost pravděpodobné, když nad tím tak přemýšlím)
c) nebo ho vyvolá po skončení skriptu S, ale Msg2 se vyvolá teprve po provedení callbacku (což je představa, která mě děsí)

nee, Msg3 nemám, v callbacku mám přesun Item do Player a ShowScreen Inventory (to možná způsobí to probliknutí)
tyhle dva příkazy jsou obaleny "if action ~= nil then" - jestli v tomhle není ten problém

[matejcik]

možná... já jsem z něčeho vyrozuměl, že při zrušení se zavolá ten skript jako kdyby uživatel stiskl button2. jestli se při zrušení volá ten callback s parametrem nil, tak to mám jednak blbě, jednak jsem to takhle nabulíkoval i účastníkům hanáckého eventu :e)) můžeš prosím zkusit tu podmínku odstranit a zjistit jak se to chová?

[Pe_Bo]

matejcik napsal/a:
možná... já jsem z něčeho vyrozuměl, že při zrušení se zavolá ten skript jako kdyby uživatel stiskl button2.
jestli se při zrušení volá ten callback s parametrem nil, tak to mám jednak blbě, jednak jsem to takhle nabulíkoval i účastníkům hanáckého eventu :e))
můžeš prosím zkusit tu podmínku odstranit a zjistit jak se to chová?

tu podmínku tam automaticky vkládá builder a nevím jak ji můžu odstranit - když ji zkusím odstranit, builder zruší celý callback

[kvapa]

matejcik napsal/a:

kvapa napsal/a:
Ahoj, vcera jsem zkousel rozbehnout OpenWig na G1 s operacnim systemem Android.

dívám se dívám
co to je za verzi j2merunnera ?

J2ME for Android v1.6

[matejcik]

kvapa napsal/a:J2ME for Android v1.6

Features 1.6.0.7
* Support JSR 82 - Bluetooth API
* Note: G1 has bug in that cannot allow app use Bluetooth server mode. only client mode is allowed.
* check /dev/socket/bluetooth & /dev/socket/dbus_bluetooth if permission is srw-rw---- then should change to srwxxrwxrwx

nemohlo by to být ono?

openwig je sice udělaný tak, aby fungoval i bez BT, ale ono kýho čerta jakým způsobem android načítá ty chybějící třídy.

[matejcik]

PeBo: tak s tím cancelem, tam skutečně má být nil. v nové verzi už to funguje - ještě dělám pár field testů (překopal jsem zhruba polovinu vnitřností, takže teď občas nefungují i věci, které už dřív fungovaly) a vydám to

[matejcik]

Pe_Bo napsal/a:
Zkoušel jsem naší novou jihočeskou O statecnem "Kacerovi" GC1KDBX a je zde problém.

Po bližším zkoumání bylo zjištěno, že OnStop event je vyvolán i v případě, že Countdown časovač doběhl a je pomocí stop zastaven. To je v rozporu s chováním jiných zařízení i emulátoru, vyzkoušeno prakticky.

Zjistil jsem ještě jednu věc - timer objekt neimplentuje Remaining property, což by měl, v emulátoru je opět přítomna (jestli je přítomna i jinde, nevím).

hele, tak jsem to teď testoval poměrně detailně v openwig emulátoru, a zdá se, že to chodí tak jak by mělo. ale tak šedá je teorie, známe to.

v listingu se píše:
>> U sane, az Vam hra rekne kam mate bezet, je potreba tuto zpravu potvrdit, nez se rozbehnete.
víme proč? ze zdrojáku mě žádný zjevný důvod nenapadá ... nebo to bylo to, že se vyvolal ten callback i když neměl?

>> V hospode pri hre se nezobrazuji cisla, ktera hodite, ale body za vitezstvi se pricitaji.
nevím čím by to mohlo být. mně se čísla zobrazovaly. ale je fakt že mám mnohem novější verzi lua stroje, možná tam byla nějaká stará a neznámá ašibka.

>> Obcas nektere textove okna zadrhavaji a obcas se jich spusti vice najednou.
no ... to je celkem nespecifický. kdy a kde by se to mělo dít?
zobrazování textových oken je teď celkem předělané, a navíc jak jsem prve říkal, ty symbiany jsou v tomhle pomalé (zejména co se týká načítání obrázků - nová verze by měla být výrazně lepší)

>> A aby toho nebylo malo, tak po posledni zprave hra spadne.
mně nespadla.
ale je fakt, že několik minut před začátkem testu jsem dodělal funkci Wherigo.Command
(teda "dodělal" - když tam je, tak to nespadne. ale funkce samotná nic nedělá.)

kdybych ti tu novou verzi poslal, myslíš, že bys byl ochoten to otestovat v terénu?

[matejcik]

tak jsem vydal verzi 0.3.90, která má spoustu nových vychytávek, předně potom je otestovaná (alespoň emulátorově) na těch českých cartridgích, které vznikly od vydání 0.3.07.

[Pe_Bo]

matejcik napsal/a:
tak jsem vydal verzi 0.3.90, která má spoustu nových vychytávek, předně potom je otestovaná (alespoň emulátorově) na těch českých cartridgích, které vznikly od vydání 0.3.07.

Díky! Tak jsem ji zkusil na naší jihočeské "O statečném Kačerovi" a super! Vypadá to mnohem líp a chová se to taky líp (zdá se mi, že už nejsou ty velké prodlevy mezi dialogy).

Jen jedna věc zůstala: pokud je vyvolán dialog, který čeká např. na OK a přijde nějaká událost, která vyvolá jiný dialog, pak tento druhý dialog jenom problikne (nejspíš je to proto, že v callbacku toho prvního dialogu je Wherigo.ShowScreen(Wherigo.MAINSCREEN), a tento callback je vyvolan, i kdyz tl. OK nebylo stisknuto) - už jsme to o pár příspěvků výše rozebírali. V jiných zařízeních to 100% funguje správně.

A ještě maličkost: pokud v nějakém dialogu odroluji dolů, pak v následném dialogu toto odrolování často zůstane (takže není třeba vidět žádný text). Neděje se to vždy - skoro mám dojem, že je to OK, když je v dialogu obrázek.

[matejcik]

Pe_Bo napsal/a:
Jen jedna věc zůstala: pokud je vyvolán dialog, který čeká např. na OK a přijde nějaká událost, která vyvolá jiný dialog, pak tento druhý dialog jenom problikne (nejspíš je to proto, že v callbacku toho prvního dialogu je Wherigo.ShowScreen(Wherigo.MAINSCREEN), a tento callback je vyvolan, i kdyz tl. OK nebylo stisknuto) - už jsme to o pár příspěvků výše rozebírali. V jiných zařízeních to 100% funguje správně.

a vidíš, to jsem myslel, že jsem opravil.
můžeš dát konkrétní případ z toho Kačera?

A ještě maličkost: pokud v nějakém dialogu odroluji dolů, pak v následném dialogu toto odrolování často zůstane (takže není třeba vidět žádný text). Neděje se to vždy - skoro mám dojem, že je to OK, když je v dialogu obrázek.

ano, to by dávalo smysl. napravím.

[Pe_Bo]

matejcik napsal/a:

Pe_Bo napsal/a:
Jen jedna věc zůstala: pokud je vyvolán dialog, který čeká např. na OK a přijde nějaká událost, která vyvolá jiný dialog, pak tento druhý dialog jenom problikne (nejspíš je to proto, že v callbacku toho prvního dialogu je Wherigo.ShowScreen(Wherigo.MAINSCREEN), a tento callback je vyvolan, i kdyz tl. OK nebylo stisknuto) - už jsme to o pár příspěvků výše rozebírali. V jiných zařízeních to 100% funguje správně.

a vidíš, to jsem myslel, že jsem opravil.
můžeš dát konkrétní případ z toho Kačera?

Např. u saně, když mám utíkat k hlavě a nezmáčknu ok v dialogu "Utikej k hlave x".

[Pe_Bo]

Tak jsem udělal následující pokus a je to opravdu tak. Vytvořil jsem cartridge s jednou zónou, jednou položkou v inventáři a jednou proměnnou (čítač). Když vlezu do zóny, zobrazí se stav čítače. Položka v inventáři má jednu akci a to dialog ("Po stisku OK se přičte 1 k čítači"), s callbackem, ve kterém se přičte 1 k čítači. V emulátoru to funguje očekávatelně - pokud vyberu položku a zobrazím její dialog (pro přidání 1), a teď vlezu do zóny, dialog zmizí, 1 se nepřičte, zobrazí se jiný dialog - stav čítače: 0 V OpenWIGu se to chová jinak: vyberu položku a zobrazím její dialog (pro přidání 1), a teď vlezu do zóny, dialog zmizí a zobrazí se stav čítače: 0 - potud to vypadá stejně. Ale pokud vlezu do zóny podruhé, zobrazí se stav čítače 1! Tj. při zrušení dialogu jiným dialogem (tím od vlezení do zóny) se evidentně provedla nejprve akce od této události a následně se poté provedl callback toho původního čekajícího dialogu. Tu cartridge ti mohu poslat, ale myslím, že to vysvětlení je zcela jasné.

[matejcik]

což o to, já poměrně přesně chápu v čem je problém, akorát jsem byl přesvědčen o tom, že jsem to už spravil ;e) kdyžtak sem prosím okopíruj kód jen toho callbacku, celou cartridge ani nepotřebuju

[Pe_Bo]

matejcik napsal/a:
což o to, já poměrně přesně chápu v čem je problém, akorát jsem byl přesvědčen o tom, že jsem to už spravil ;e) kdyžtak sem prosím okopíruj kód jen toho callbacku, celou cartridge ani nepotřebuju

cartTestDlgCancel.MsgBoxCBFuncs.MsgBoxCB3 = function(action)
if action ~= nil then
-- #GroupDescription=PridejOK --
-- #Comment=PridejOK Comment --
Counter = Counter + 1
end
end

[matejcik]

no jasně. blbá chyba. jsem to opravil s těmi dialogy, díky té opravě vznikla chyba, chybu jsem odstranil ale s tím jsem zrušil i tu opravu ... no ... nic. teď už to bude fungovat.