787 odpovědí na toto téma

[matejcik]

Citace

Varouch napsal/a:
A tyto funkce už nějak v LUA nevygeneruju, ne?
Řešila by to dědičnost, kdy předek by měl tu potřebnou metodu a dala by se volat u všech potomků, to tady ale neudělám. Nebo ano?

Dědičnost by to neřešila (resp. ne jen tak sama od sebe), klíčové je to použití proměnné "self" místo konkrétního předmětu. Pokud si funkce na ošetření příkazů napíšeš v Lua, tak to můžeš udělat tak, jak jsem naznačil.

[matejcik]

ne, takhle to nefunguje.
kromě toho, OnpouzijVec už parametr má - je to parametr předmětu, který by dostala jako CmdWith (příkaz použitý z jedné věci na nějakou jinou)
Nicméně šlo by něco podobného. Pokud ten parametr nepotřebuješ, můžeš si vyrobit příkaz na nějaké skryté věci, který bude s tímhle parametrem pracovat:

function skrytaVec:OnZpracujOstatniVeci(target)
target:MoveTo(Player)
end

a pak si napíšeš jednoduchou Lua funkci, která vyvolá tenhle skrytý příkaz

function predejDal(self)
skrytaVec:OnZpracujOstatniVeci(self)
end

a pak nastavíš tenhle příkaz těm ostatním věcem: aVec[x].OnpouzijVec = predejDal

pozor:
tohle přiřazení tu funkci nastavuje, ne volá. proto tam nejsou žádné závorky, a proto nefunguje tvůj příklad, kde bys tam závorky s parametrem předal.

pozor2:
v definici funkce predejDal píšu parametr "self" explicitně. to je proto, že je ta funkce definovaná samostatně a ne na nějakém předmětu. parametr self tam patří, zatímco do definice funkce skrytaVec:OnZpracujOstatniVeci nepatří

[matejcik]

ale mezi námi děvčaty -- už je to docela dost Lua kódu spotřebovaného na to, abys nemusel psát další Lua kód ;e) a to nemluvě o tom ohýbání Urwiga

[mh.mail]

Citace

Varouch napsal/a:
...

Na otázku odpověděl matejcik.

Já bych jen dodal, že tady už se dostáváš do nižších úrovní jazyka LUA a bez znalosti principů událostmi řízeného programování a pojmů jako událost (event), obsluha události (event handler) a způsobu, jak se to implementuje v LUA, to půjde těžko.

Udělat se dá leccos a lecjak, ale otázkou je, jak to bude komfortní v rámci návrhu v Urwigo, a ještě důležitější otázkou je, jak to bude stabilní při běhu na jednotlivých přístrojích.

Možná by bylo vhodnější se na to jít podívat z opačné strany:
Máš velké množství předmětů se stejnými příkazy. CO je to za předměty? Mohou být aktivní současně (tj. budou se vyskytovat v inventáři stejné zóny, případně v inventáři hráče současně)? Anebo vždy bude aktivní pouze jeden z nich?

[matejcik]

to jsem se zrovna chtěl zeptat. na co potřebuješ 150 předmětů? nešlo by to chytře obejít s použitím několika málo zobrazených v pravou chvíli? navíc pokud by se těch 150 předmětů mělo někde ukazovat naráz, uživatel by se z toho zbláznil a vsadil bych se, že ani takový Oregon by z toho nebyl nadšený. (koneckonců, za svůj openwig v takové situaci bych též ruku do ohně nedal)

[mh.mail]

Citace

Varouch napsal/a:

Citace

mh.mail napsal/a:

Citace

Varouch napsal/a:
...

Mohou být aktivní současně (tj. budou se vyskytovat v inventáři stejné zóny, případně v inventáři hráče současně)?

Ano, mohou. A i kdyby ne, co se tím mění?

Dost věcí. V takovém případě bys mohl mít nadesignovaný JEDEN jediný předmět, ve kterém bys při jeho aktivaci pouze měnil obrázek, popisek apod. podle situace. Nemusel bys řešit přiřazování handlerů, self a podobné věci.

Ono někdy řešení zdánlivě neřešitelného problému leží mimo původní směr zkoumání. Zkušenost mě naučila, že když zabřednu na dlouho do nějakého problému, jehož řešení je komplikované a zamotané, že není na škodu udělat Cimrmanův "úkrok stranou" a zkusit se nad tím zamyslet odjinud. Ne vždycky to samozřejmě pomůže, ale dost často jo.

[mh.mail]

Citace

Varouch napsal/a:
Takže teoreticky by mi stačilo 5 předmětů a podle vzdálenosti od jednotlivých bodů (které bych měl v nějakém poli spolu s názvem, popisem,...), bych měnil vlastnosti těchto 5 předmětů?

Nejspíš ano, ale stoprocentně bych ti to byl schopný říct až poté, co bych věděl, co přesně a k čemu chceš použít.

Citace

Varouch napsal/a:
Jen nechápu, proč tak moc zavrhujete to řešení přes skrytou věc, které jste sami navrhli.

Já ho nenavrhoval
A zavrhovat je silné slovo, spíš bych řekl, že se ho bojíme. Podívej, každý wherigo objekt (zóna, předmět, úkol, vstup, časovač, médium) při své inicializaci zabere určitou část volné paměti přístroje. U novějších mobilů už s kapacitou paměti nebude takový problém, ale Oregony a nedej bože Colorada té paměti nazbyt nemají. A wherigo objekty nemají jenom název, popis a souřadnice, ale i spoustu dalších atributů, které se sice třeba nepoužívají, ale paměť si užerou stejně. Proto definování velkého počtu wherigo objektů může být potenciální problém především pro Garminy. To je pak to nenáviděné nečekané vypínání přístroje - prostě mu dojde paměť a tak to vyřeší vypnutím.
Takže pokud bys psal program pro normální zařízení s dostatkem paměti, pak je tebou navrhovaný způsob určitě systémovější a správnější. V případě wheriga je však dobré myslet na alternativní způsoby řešení, které jsou paměťově méně náročné.
Malý příklad: Udělal jsem cartridge, která obsahujovala 92 zón, 40 předmětů, 19 úkolů, 10 vstupů, 3 časovače a 188 médií (obrázky + zvuky). Telefon bez problémů, Garmin 300 nejprve nedokázal obnovit po uložení (prostě se vypnul), později už se nedokázal ani nastartovat (pár vteřin po startu se vypnul). Nakonec mi nezbylo nic jiného, než to rozdělit na 3 samostatné cartridge. Prostě Garminy nejsou nafukovací.

Citace

Varouch napsal/a:
... jako ohýbání URWIGA mi to nepřipadá. URWIGO je nástroj který vizualizuje nejběžnější postupy, takže není potřeba znát LUA. A když něco neumí, tak se to prostě napíše ručně....

Ano, tady s tebou souhlasím. Termín "ohýbání Urwiga" je podle mě nešťastný. Urwigo je opravdu jenom builder, který nakonec vytvoří LUA kód, který se pak zkompiluje a použije. Stejně tak je možné cartridge napsat v textovém editoru přímo v LUA a žádné Urwigo k tomu nepotřebuješ. Jen to tedy není vůbec komfortní.
Tím "ohýbáním Urwiga" kolega asi myslel to, že u všeho, co napíšeš přímo v LUA a nesestavíš si to v Urwigo diagramu, se ochuzuješ o některé komfortní možnosti, které ti Urwigo dává. Prostě si to už pak musíš ošéfovat v LUA sám.
Mně se zatím osvědčila rozumná kombinace obého - základem jsou diagramy v Urwigu doplněné o speciální kódy přímo v LUA pro úlohy, které se v diagramu buď udělat nedají vůbec anebo zbytečně komplikovaně.
Takže z mé strany to odrazování od tebou navrhovaného řešení je spíš z důvodu možných problémů s dostatkem (nedostatkem) paměti především u Garminů.

[matejcik]

Já řešení přes skrytou věc nezavrhuji, jen mi to připadá jako drbání levou nohou za pravým uchem. Když ti stojí za to si Lua trikem zařídit, abys mohl tu jednodušší část naklikat...
Nicméně ohýbání to rozhodně je. Takový trik, kterému teď rozumíš, ale pokud ten samý trik neuděláš v každé další cartridgi, tak budeš za rok zadumaně hledět, jak je možné, že to funguje, když tam nemáš definované žádné příkazy, a k čemu tam sakra slouží ten skrytý předmět.

Ten případ s patníky mi přijde jako docela platná situace, kdy využít 65 předmětů. Ono nakonec nejspíš vyjde dost nastejno, jestli máš 5 předmětů a tabulku 65 souřadnic, nebo rovnou 65 předmětů. 65 předmětů zabere víc paměti (byť ve srovnání s jednou fotkou do zóny je to pořád málo), s tabulkou souřadnic bude zase komplikovanější kód.
Ale tam by už stálo za to jít o krok dál a ty předměty opravdu generovat. Třeba nějak takhle:

souradnice = {
ZonePoint(50,14,0),
ZonePoint(51,14,0) .... 
}

patniky = {}
for i = 1, #souradnice do
  local patnik = ZItem{Cartridge=cart, Container=skrytaZona}
  patnik.Name = "Patník č. " .. tostring(i)
  patnik.Description = ""
  patnik.Commands = { .... }
  patnik.ObjectLocation = souradnice[i]
  -- atd.
  patniky[i] = patnik
end

ani jeden z těch patníků pak nebude v Urwigo vidět, ale to je vlastně dobře - znamená to, že je nemusíš oklikávat, že každá změna se okamžitě projeví u všech najednou.
z čehož je rovnou jasná i nevýhoda - kdybys pak potřeboval, aby jeden z nich byl nějak speciální, budeš to muset buď napsat ručně, nebo ho z tohohle seznamu vyhodit a udělat ho v Urwigo samostatně.

Každopádně bych se ale přimlouval za to, aby 150 předmětů nebylo vidět najednou. Už těch 65 je na pováženou. Je fajn, že to smartphone zvládne, ale jeho uživatel bude mít problém ;e) Sám máš v popisu cartridge, že se Navigátor může hodit pro přehlednost.
Napadá mě třeba tohle: rozházet předměty do několika zón, a pak ukazovat vždy jen tu skupinu z aktuální zóny a navigaci k dalším "skupinám".

[matejcik]

(jen dodávám, že osobně mám z Garminů nedefinovaný děs a hrůzu a zprovozňovat na nich cartridge jsem nikdy nezkoušel. mluví-li kolega mh.mail o vyžrané paměti, bude lépe věřit jemu)

[prazskychytrak]

Měl bych dotaz, jak udělám v Urwigu, abych v zoně odpovídal na sérii otázek, což se následně vyhodnotilo, kolik bylo správných odpovědí a podle toho se zobrazila konkrétní odpověd? Dík

[Blexa]

Vstup 1-X, do promenne ukladat bod za spravnou odpoved a na konci zobrazit zpravu podle hodnoty promenne.

[prazskychytrak]

Supr, díky;)!

[prazskychytrak]

Tak ještě dotaz:) jak u vstupu nastavím pouze jednu správnou odpověd? Ve zkratce, zatím jsem přišel pouze na možnost "porovnej" ve "když/jinak", při více odpovědí, ale jen "porovnej" a jednu jedinou odpověd, nevím kam vložit. Nebo nevím, jak udělat, aby program poznal, že vložené slovo je správné. Díky

[Blexa]

Reseni je prave pomoci kdyz/jinak a porovnavani opovedi. Zkus to prosim nejak rozepsat nebo upresnit, protoze nejak nevim co mam presne radit...

[prazskychytrak]

Mám vstup s textovým polem, kam má hráč zadat jediné slovo, které bude správné, pokud zadá jiné špatné, nepřipočte se mu bod. Ale i když jsem do volby výběru zadal požadované slovo, při získání odpovědi dal plus bod a při chybě nastavil 0 bodů, program zřejmě nerozpozná, že nedošlo k chybě a posílá bod, i když do pole napíšu chybu:) no a když dám když/jinak, při chybě vypadne hráč z dialogu a musí odpovídat znovu a "jinak" jsem musel nastavit na konkretni odpoved, treba "nevim"