Sub-application e Inventario

Fala ae galera, bleza?

Mais uma duvida pois fiz algo errado....kkk

Bom, eu criei um sub-application que é um inventario (tipo Diablo).
La estão minhas poções e tals.
Clico em alguma poção, ela faz a função que tem que fazer e some do inventário (destroy). Aperto a tecla I e saio do mesmo.
Só que quando abro ele, a poção esta la novamente.

Obs: As poções são actives.

Que merda que eu fiz???....kkkk
Valeu!

Se você tá usando SubApp é porque existe um frame que contém o inventário, né? Pois é, aí que tá.

É complicado eu te dizer qualquer coisa assim, até porque não sei como tá a tua engine. Mas a minha teoria é que você simplesmente colocou as poções no frame do inventário, sem nenhum controle. Cada vez que você abre um SubApp, se não me falha a memória, é como se ele reiniciasse o frame. Daí, se você colocou as poções diretamente no próprio frame, elas vão ser carregadas sempre que o frame for aberto em SubApp.

Pra resolver isso, cria uma variável global que contenha o numero de poções de HP, por exemplo. Daí nos eventos do frame do inventário, coloca pro número de poções ser igual ao contido na variável global. Quando o jogador usar uma poção, ele vai subtrair um da variável global. Se a variável global for 0, destruirá o ícone das poções, indicando que não tem nenhuma.

Esse negócio de inventário é bem complexo. É importante que vc entenda a ideia do que eu disse aí, mas não fazer ao pé da letra, porque isso eu disse considerando só as poções. E, claro, haverá outros itens no seu inventário.

Abraço.

Exatamente isso.

O sub-app é um frame onde estão as imagens das poções (active).
Entendi o esquema de reiniciar o frame, agora vou tentar fazer a variavel global com o numero de poções e tentar linkar com a o active.

Valeu.

Se você souber inglês, dá uma olhada na ajuda do mmf2 sobre sub-application.
Um menu de pause é fácil de fazer. Cria um global value com o número de poções e faça:
Número de poções (global values) > NObjects (active poção):
(Poção) Destroy

Deixe a Sub-Application numa layer sobreposta à principal. Aí, é só "sumir" com ela quando não quiser que o inventário apareça.

OBS: O MMF2/CF2.5 não tem uma opção pra alterar a visibilidade de uma layer nativamente, é preciso da extensão "Layer Object".

Hey, acabei de terminar de fazer uma matéria sobre sub-application, traduzi da ajuda original do mmf2. Download:

https://www.dropbox.com/s/4kgriqkvckl4npg/MMF2%20-%20Sub-Application%20tutorial.pdf

Firmeza pessoal, valeu pela força!

ok, vai lá! Vou escrever sobre spread values, talvez te ajude em algo.

Opa, valeu Davi!
Assim que tiver concluído vou compartilhar com vocês do fórum.
Mas já aviso, é uma coisa bem simples que estou fazendo com meu filho!

Obrigado. Essa matéria traduzida sobre sub application é a primeira de uma série de tutoriais traduzidos inéditos em português, feitos por mim. A próxima, como disse, vai ser sobre spread values.

Ta muito show cara!

Quando vc tiver tempo, tenta fazer alguma coisa que explica melhor sobre Layer e Toggle. Principalmente este segundo, estou muito confuso sobre como criar interruptor.

Tipo, se apertar a tecla A abre tal coisa, e se apertar a mesma tecla fecha.

Toogle é isso aí mesmo cara. Existe uma explicação um pouco mais longa sobre variáveis booleanas, mas, trazendo pra realidade do CF2.5, basta pensar em flags como interruptores. Você pode ligá-las ou desligá-las. Não há necessidade de criá-las, pois cada Active Object já vem com várias flags prontas pra você usar. As flags são identificadas pelo objeto que as contém e por um número (ex: flag 3 do Active Object "Personagem"). Elas funcionam independentemente. Isso quer dizer que você não precisa ter usado a 0, a 1 e a 2 para usar a 3, por exemplo. A flag 3 de um dado Active Object funciona perfeitamente sozinha. Apesar disso, você PODE programar uma cadeia de eventos na qual uma flag sairia ativando ou desativando outra(s). Elas não possuem relação entre si, mas VOCÊ pode criar uma relação entre elas se assim precisar.

Vamos pensar nas flags como interruptores para facilitar o raciocínio (até porque é basicamente isso). O toogle nada mais é do que uma função que inverte o estado do interruptor: se estiver ligado, desliga... e vice-versa. Por outro lado, você pode forçar estados a esse interruptor. A diferença é que forçar um estado não depende de como ele estava antes. Confuso? Tenta ver esse esquema.

Usou toogle?
1. O interruptor está ligado: desliga o interruptor
2. O interruptor está desligado: liga o interruptor

Forçou a desligar o interruptor?
1. O interruptor está ligado: desliga o interruptor
2. O interruptor já está desligado: mantém o interruptor desligado

Forçou a ligar o interruptor?
1. O interruptor já está ligado: mantém o interruptor ligado
2. O interruptor está desligado: liga o interruptor

Ou seja, quando você força um novo estado ao interruptor, ele simplesmente ignora o estado anterior. Vai ser aquilo que você mandou, e pronto. Mas quando você usa um "toogle", ele troca o estado. O novo estado depende do antigo.

Layer, por outro lado, é uma coisa totalmente diferente. Em português, Layer significa "Camada". É a mesma noção usada no design: uma forma de agrupar objetos.

Considere, por exemplo, duas camadas. Suponha que a segunda camada está acima da primeira (você muda a posição delas pela janela de Camadas). Então, todos os elementos contidos na primeira camada ficarão SOBRE os elementos da primeira.

Suponha agora uma terceira, acima da segunda. Todos os objetos inseridos nessa terceira camada ficarão sobre os objetos da segunda e, consequentemente, da primeira. Ou seja, caso um objeto da segunda e outro da terceira camadas ocupem uma mesma posição, é o objeto da terceira que ficará em cima.

O menu de layer serve simplesmente para organizar a ordem dos objetos, ou seja, quais objetos vão ficar em cima de quais. No CF2.5 isso pode ser extremamente útil porque alguns objetos, como Backdrops, sempre ficam embaixo de outros, como Actives. Trabalhando com apenas uma layer, você nunca conseguiria fazer um Backdrop ficar em cima de um Active, mas, colocando esse backdrop em uma layer superior, isso seria possível. A ideia é a mesma da utilizada no design. Há uma sutil diferença, mas não vem ao caso. Só iria confundir...

Se tiver qualquer dúvida, pode ficar a vontade pra perguntar. A gente tá aqui pra ajudar

Firmeza Eskyz, vou tentar aqui e qualquer duvida escrevo.

Valeu pela força!

De nada cara! Fique a vontade

A propósito, acabei me equivocando em um ponto da explicação, por falta de atenção. Editei ali o post, agora está correto. Marquei a parte corrigida em vermelho para você saber qual foi. Desculpe por isso.

Evite usar o Sup-Application para isso. Ele serve mais para rodar outros frames ou aplicações no mesmo frame. Pra fazer um Inventário, o melhor é usar outra Layer mesmo. Além de ser mais simples de fazer, fica mais leve, não precisa utilizar variáveis globais e pode ser feito com mais detalhes.

Assim que der, vou tentar fazer usando layer.
Ai escrevo aqui como foi!

Obrigado pelo elogio, leo. Tentei ser mais formal possível, antes de publicar aqui, revisei a matéria muitas vezes. Use flags com layer object, igual o matheus falou Aí o menu fica show. Eu não sabia que sub-application gastava memória.

Peraí, vc não disse por mp que tava seguindo o curso do eskyz? como você me diz que não sabe o que são flags e layers?

Li até, mas entender ta difícil.
Não sei pq ainda não consegui ligar meu conhecimento de VB e C# com o Fusion.
Eu até tenho a logica, mas na hora de fazer trava meu cérebro.
Mas é bloqueio, ja tive isto antes.
Talvez seja melhor desistir e tentar ano que vem.

Não faça isso. Eu fazia isso quando comecei a aprender a mexer no Unity. Eu queria passar meu conhecimento de MMF pro Unity. Pior viagem, é tudo diferente. Dá pra ser aproveitado a lógica de programação, mas a "arquitetura" (se é que posso chamar assim) é bem diferente. É preciso reaprender.

Vou tentar não desistir, mas não é fácil.
Eu manjo o conceito, mas fazer no fusion me atrapalho.

Valeu peal ajuda de vcs.

vc pode criar um evento de fastloop pra carregar o inventario sempre que clicar no atalho dele, e deletar os graficos do inventario apos clicar novamente no atalho, assim vc deixar sua aplicação mais leve, se vc apenas esconder o inventario isso pode causar lag no seu jogo dependendo do numero de itens no seu inventario e numero de itens na tela do jogo.

vc so precisa guardar as informações do seu inventario em um unico active utilizando as alterable value ou alterable string, da forma que melhor guarde sua informação.

Não sei se deu pra entender, caso pretenda fazer deste modo e quiser ajuda, eu to aqui para auxiliar, flw ae boa sorte.

Leo, não é meio complicado ficar criando e destruindo o inventário toda hora? eu usaria sub application mesmo, é bem mais fácil, ainda que gaste memória.

As matérias do eskyz mais fácil e compreensível não existem. como você me diz que não consegue aprender com as aulas dele?

Na teoria é complicado, mas evita varios problemas, como uso de memoria, cliques indesejaveis no inventario, tendo em mente que o inventario invisivel ainda poderia ser clicado, podendo gerar algum conflito em meio o jogo, para evitar os cliques inapropriados teria que fazer mais algumas linhas de evento limitando os cliques e o uso do inventario, bem alem que se vc quer fazer um jogo leve, sem bugs e sem travar, esse seria o modo ideial.

e fazer isso não seria dificil, basta conhecer a ferramenta.

Bem, vou fazer um exemplo rapido aqui e já posto.

Engine Inventario Loop

Ae esta, não sei bem explicar como funciona, so sei como se faz, ate por isso preferir fazer do que tentar explicar, claro que falta implementar, mas isso é mais facil, cada slot do inventario tem seu id, basta passar o mouse por cima dos quadrados para ver sua id, ae so basta usar seus alterable value e string para guardar as informações sobre o conteudo do inventario, aconselho a usar as alterable do objeto com nome de "Inventario" pois ele é o unico que não é destruido nos loops, espero ter ajudado.

é só fazer o seguinte:
se o menu ta visível, alguma flag fica ligada, e se ta invisível, a flag fica desligada. Aí no evento click, é só verificar se a flag estiver ligada. Já fiz vários menus, com sub app ou não, e não afetou na memória e nem deu lag.

O bom da programação é que existem varias formas de se fazer um sistema, o modo leve, o modo pesado e o modo eficiente, isso implica no resultado final do projeto, quanto mais objetos em cena, mais memoria usará, qto mais subapp, mais processamentos usará, pra que deixar objetos em cena que não esteja usando? pode ate não dar lag, no seu pc, mas um programador tem que fazer algo que seja executavel em varias plataformas diferentes e reduza ao maximo a possibilidade de lag, ainda mais quando de trata de jogos, mas bem, os dois modos são viaveis ao final do projeto verifique quantos objetos invisiveis seu jogo tem em cena e quanto de memoria está sendo disperdiçada.

então o meu modo é fácil, pois uso sub-application sempre para menus.

Sub-Application limita e pesa. Para fazer um projeto (ou jogo) funcionar dentro de outro, tudo bem, Sub-Application é ótimo. Mas para fazer um inventário não. Antes usar uma Layer ou por Loopings como o Leodigaum falou.

E Leodigaum, se tiver no Direct3D 9, pode colocar uns 500 objetos (por exemplo) com Alpha Channel, Anti-Aliasing e qualidade máxima, rotacionando e alterando escala o tempo todo, que não vai pesar. Então, usar o inventário numa layer invisível e bloquear o grupo de eventos relacionada à ela, acredito que seja melhor que ficar criando e excluindo os objetos por looping, pois no momento que se cria vários objetos simultâneos perde um pouco de desempenho. Mas claro que se não houver muitos objetos no inventário (200 por exemplo), aí não tem problema.

Então, o que eu falei. ficar criando objetos e destruindo toda hora que o jogador ativar o menu de pausa dá muito trabalho, ainda mais para o leofylin que é iniciante, uma técnica dessas seria muito complicada para ele.

Eu confesso que nunca me ligo muito em memória. Sempre faço do primeiro jeito que dá certo. Mas o interessante é ver que realmente existem várias possibilidades pra chegar a um mesmo resultado.

@Davi: obrigado pelo elogio cara, fico realmente feliz! Mas verdade seja dita: muitas das matérias da MMFM não estão legais. A MMFM caminhou comigo. São perceptíveis até minhas mudanças de discursos nas matérias. Comecei o trabalho no blog com 11 anos, hoje tenho 17. Inevitavelmente, as primeiras matérias tem um nível de qualidade muito baixo devido à minha pouca maturidade na época.

Como já foi dito aqui, existem varias formas de se fazer a mesma coisa, o processo de looping em jogos e mais antigo e mais comum do que muitos imaginam, o proprio sistema de particulas é um exemplo bem notavel, ondem tem particulas que se criam mais de uma centena de imagens em menos de 1 segundo e são disparadas e rotacionadas variadamente e ate mesmo ampliadas ou reduzidas dependendo do efeito da particula e vão se destruindo gradativamente ou simultâneamente, ou seja, criar e destruir centenas de objetos em poucos segundos não é algo pesado ou absurdo, afinal, isso é uma tecnica utilizada desde os jogos de atari e repetida ate hoje nos grandes jogos top de linha.

É claro que cada pessoa escolhe o seu metodo de trabalho, cada um se sente mais avontade em mexer com aquilo que é mais habituado, os sistemas de looping costumam assustar um pouco, ainda mais quando se combinam varios loopings um dentro do outro, como eu fiz no sisteminha que postei.

Enfim, o bom é que agora o leofylin tem varias soluções para o mesmo problema rsrs.

pois é, agora são 3 opções. Eu optaria pela opção de mostrar/esconder os objetos do menu.

Davimmf2 escreveu:As matérias do eskyz mais fácil e compreensível não existem. como você me diz que não consegue aprender com as aulas dele?

Bom, agora com mais tempo para ver o caso, percebi uma coisa neste tuto do nosso amigo.

Esta assim:

Hora do Exercício!
Agora vamos fazer algo com o que acabamos de aprender.

("Active"): internal flag 0 is off
(Active) Reappear

("Active"): internal flag 0 is off
(Active) Make Invisible

Upon Pressing "Enter"
(Active) Toogle internal flag 0

Mas o certo não seria assim?

Hora do Exercício!
Agora vamos fazer algo com o que acabamos de aprender.

("Active"): internal flag 0 is ON
(Active) Reappear

("Active"): internal flag 0 is off
(Active) Make Invisible

Upon Pressing "Enter"
(Active) Toogle internal flag 0

Fiz do segundo jeito e funcionou.
Não sei se foi por isso que não consegui fazer da primeira vez que tentei, pois fiz igual ao site.

Mas to aprendendo, valeu galera pela força.

O certo realmente é o segundo modo. Falha minha. Falta de atenção ao escrever. Como já pode ter percebido, tenho esse probleminha... ^^'

Firmeza Eskyz, sem problema.
É que fiquei tentando e tentando e nada.
Este fds com a cabeça mais tranquila voltei a mexer e vi o erro.....rs....

Estou sem tempo para mexer, por isso não to escrevendo com frequência.

Não é melhor usar flags com layer object? aí a layer fica invisível. Vou pra escola daqui a pouco e só volto às 18:00. Depois que eu chegar ensino
a você o método.

Cara, tenta raciocinar e fazer sozinho, ficar olhando toda hora e fazendo igualzinho ao site não funciona. Leia o tuto com atenção e faça igual depois. Treine até que você saiba fazer sozinho, sem ajuda de tutoriais.

leodigaum escreveu:Na teoria é complicado, mas evita varios problemas, como uso de memoria, cliques indesejaveis no inventario, tendo em mente que o inventario invisivel ainda poderia ser clicado, podendo gerar algum conflito em meio o jogo, para evitar os cliques inapropriados teria que fazer mais algumas linhas de evento limitando os cliques e o uso do inventario, bem alem que se vc quer fazer um jogo leve, sem bugs e sem travar, esse seria o modo ideial.

e fazer isso não seria dificil, basta conhecer a ferramenta.


Ae esta, não sei bem explicar como funciona, so sei como se faz, ate por isso preferir fazer do que tentar explicar, claro que falta implementar, mas isso é mais facil, cada slot do inventario tem seu id, basta passar o mouse por cima dos quadrados para ver sua id, ae so basta usar seus alterable value e string para guardar as informações sobre o conteudo do inventario, aconselho a usar as alterable do objeto com nome de "Inventario" pois ele é o unico que não é destruido nos loops, espero ter ajudado.

bom para usar um inventorio de layer onde não ouvese bugs com supostos cliques com objetos invisiveis bastaria ele ter o controle da visibilidade da layer utilizando layer object e colocando toda a programação do inventorio em um grupo

onde se a layer do inventorio estivese visivel o grupo seria ativado e quando estivese invisivel o grupo desativaria e toda a programação contida nele seria nula ..

Exatamente, isso é praticamente o que eu comentei em relação de este modo ser obrigatório criar um sistema apenas para evitar os cliques indesejaveis e conflitos com menus invisiveis

"...para evitar os cliques inapropriados teria que fazer mais algumas linhas de evento limitando os cliques e o uso do inventario..."

E é claro, lembrando que item invisivel ainda está sendo carregado na memoria... ou seja, leve por leve, talvez manter algo carregado na memoria que não vai ser utilizado no momento não seja o metodo mais leve.

Eo mais viavel e utilizar uma sub aplicação externa com banco de dados se quiserem eu faço uma engine