Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pmBoard: International
MkTendou is Offline
Contact MkTendou:
Profile Info
Show content
This section allows you to browse the content for this member. Note that you can only see content for which you have sufficient viewing permissions.
Messages by MkTendou
Page 1 of 11
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pm
Board: International
Acredito que pessoas que usam adfly ou qualquer link desse tipo pra lucrar em volta de personagens mugen que não foram criados de sua autoria (acho que na vdd mesmo com sua própria autoria ja que mugen nao foi criado pra ser lucrável) poderia ter sua conta bloqueada no Youtube por exemplo.
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pm
Board: International
Eu ainda estou usando o FFClassic XD
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pm
Board: International
. Espero que goste!
. Aliás, eu também queria ver seus chars, mas no seu perfil daqui não tem o endereço do seu site. Onde posso baixar?
No momento eu estou dando uma breve Att de HUD pra eles com certas novas mecânicas, então quando eu os lançar aviso. Porém meu estilo de char é de arte antiga, como eu apenas no momento gosto de codificar apenas naruto (como vc viu me mencionar o código do genjutsu da escuridão infinita) porém meus chars são do estilo SND (então é uma coisa bem antiga mesmo) que geralmente as pessoas não gostam muito pelo tamanho. Talvez por isso fiquei mais nos sites Ucoz em vez de forums grandes como esse nesse tempo todo.
Eu discordo totalmente. Se é algo que pode ser benéfico (mesmo que seja um erro), deve ser compartilhado. Existem pouquíssimas informações que não devem ser compartilhadas, mas não vejo o Mugen como um caso desses.
O exemplo do Cond foi que, depois de mais de 10 anos as pessoas continuam usando ainda o IfElse, não que o Ifelse está totalmente errado (mas a lógica de como ele lê parcialmente está errado) mas é como eu falei com o amigo ali usando um exemplo de game em Flash Player: o game ainda vai ser topzão porém doq adianta usar uma lógica tão antiga ao ponto de ja estar morrendo? É tipo essas templates de mecânica que tem por aí que enche pra caramba seu -2 ou -3 sendo que na vdd vc poderia fazer o mesmo código com 20% do tamanho.
A única coisa que explica o uso de IfElse é: ou a pessoa está apenas sobrevivendo de templates, ou não liga muito ja que tudo funciona, ou simplesmente que nem vc falou no final: apenas quer tudo dado nas mãos sem fazer esforço.
Motivo que, depois de mais de 1 década que o Cond atua assim e ninguem percebeu pq cond foi ignorado, a gente acabou revelando.
O que eu falei sobre "há coisas que devem ficar enterradas" são coisas que se reveladas apenas vai evoluir esse câncer tóxico da comunidade mugen que vc mesmo mencionou. Eu sei muito bem que OpenBor é pequeno, mas o ponto sempre foi qualidade acima de quantidade e não o contrário.
Exemplos de coisas que não vou ensinar como faz:
Eu posso bloquear todo o seu -1 (CMD) do seu char, então vc não iria fazer exatamente NADA;
Eu posso simplesmente negar toda a sua AI baseada em p2dist ou até mesmo impedir que ela detecte que eu estou atacando ou que foi acertada por um ataque (pra caso que exista counter) ou até mesmo como falei pra o amigo ali, criar um char que não tenha Hitko e usando a AI default do mugen que poderia derrotar tudo, até mesmo os cheapie do winmugen. Mas ai está a questão: mugen virou um circo de coisa tosca, hentai e vore que se eu realmente fosse a Elecbyte ja mudaria o stats da engine pra abandonware. Até da pra perceber pq eles não tão nem aí mais pq eles não tão inativos, estão trabalhando em outras coisas nada relacionado a game. Então se eu ensinasse isso o mugen iria ficar pior ainda (o que a gente pensa que não pode ficar mais pior, mas acaba ficando...)
Outro ponto que discordo. Vc pode argumentar que seria melhor terem vários níveis de AI, de maneira progressiva, etc. Mas argumentar que ela não deveria pressionar sem dar uma change de recuperar me parece bastante equivocado, pq derroto o propósito de se ter uma AI.
No meu entendimento, ela deve te pressionar o tempo todo - pq eu mesmo jogo assim. Só paro de pressionar se eu achar que o risco não vale a pena. E esse é um ponto que eu deixo em aberto nas minhas AIs, para que seja explorado de propósito.
Isso na verdade depende da interpretação de quem está no comando. Inteligência Artificial na minha opinião não é ir pra cima "que nem um macaco raivoso gritando pra garantir win" pq aí vai contra o significado de INTELIGÊNCIA Artificial. É saber interagir como se fosse um player real. A questão é que muita gente só fica contente se a AI do char derrotar todo mundo e isso tbm não é significado da AI ou se o char estar bom (o que garante uma evolução se vc oferecer um feedback racional). Codificar por níveis pra mim é o correto (ou seja, o intervalo de parar de pressionar tbm depende da dificuldade, mas DEVE ter um intervalo que vc pare de pressionar e isso nunca vai significa que sua ai é ruim, ela só é estratégica ao ponto de o inimigo não se entediar fácil e não querer o char).
Porém esses debates fazem um conhecer melhor o outro e saber o que cada um faz já que ninguem aqui tá dizendo que o outro está errado (discordar de pontos tbm não significa isso)
Vou te dar um exemplo do seu Enke. Meu char não usa esses tipos de AI que vai pra cima com tudo usando chuva de combo (porém ele tbm não é burro, duh), mas ele se adapta a SUA AI, como o seu Enker é um tipo que pressiona constantemente o char, ele mesmo acaba perdendo por causa do seu próprio AI, é como se minha AI simplesmente "absorvesse sua AI e se tornasse melhor que ela". Por isso que desenvolvi uma AI assim, e ela está relacionado a dificuldade do jogo + ao mesmo tempo se adapta com outras AI ou seja, quando é contra player, ela age normal baseado na dificuldade a não ser que vc vire apelativo. Quanto mais chain combo vc spammar em tempos que são detectados como "já está apelando sem necessidade", vai acabar sendo derrotada.
Porém não significa que meus chars vão "absorver a AI inimiga" e sempre vencer, eles já perderam pra certas AI tão estupidas que até eu me surpreendi mas tbm não modifiquei nada pq ja demonstra que se adaptam contra tudo e não fazem o combate ser "injusto"
Posso usar inclusive o Mugen como exemplo: muita gente tem mania de compactar vários triggers na mesma linha, como se isso fosse "otimizar" a programação. Quando, de fato tem o efeito contrário (é um hábito ruim que se pega quando se aprende a programa com mugen). Se um triggerall precisa ser cumprido, ele deve ficar isolado na linha.
Isso eu concordo com você por ser Triggerall 
. E como vc pode ver, eu não compactei triggerall, mas eu esqueci de apontar esse detalhe em não colocar no triggerall.
Vc é macaco velho e já sabe de cor e salteado essa máxima aqui: vc faz as coisas PRA VC e quem tem que gostar é VC. Vc disponibiliza para quem quiser usar, mas o foco foi, originalmente, vc. Feedback é sempre bem-vindo, para que todos possam fazer as coisas da melhor maneira possível. Mas muita gente pegou a mania de achar que todo mundo tem que fazer algo do jeito que acham que é e tudo que não for feito dentro daquele padrão "não presta".
Isso é outro ponto ultra importante, mas não pra o "seu Eu codificador" e sim pra o "seu eu psicológico". Hoje em dia existe muita gente gostando de personagens que, mecanicamente é estranho e tem outras que gostam. Muita gente ja ignora o char no roster justamente por causa do estilo de arte (o que é irônico pq os jogos mais icônicos não tem arte boa) ou até mesmo amostra falhas que não gostaram sendo que os personagens que gostam TAMBÉM tem essas falhas mas tem aquela leve iludida por causa que é um char que gosta vs um char que não gosta ou nunca ouviu falar. O char você está criando do seu coração, mugen é muito simples, mas também não significa que vc vire escravo de outra pessoa.
Feedback racional tbm ajuda muito o desenvolvimento. Um feedback dizendo que "não gostei pq bla bla" mas de um modo que vc percebe que o problema ta na pessoa então vc realmente n vai levar a sério.
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pm
Board: International
. Execução imediata. Por isso o "ChangeState" é o último item. Não tenho como confirmar que isso tem mais prioridade do que o "time = 0", mas é a impressão que me dá.
Normalmente a gente trata como se o mugen lesse tudo na ordem que a gente coloca, o que realmente acontece, ele lê de cima para baixo mas não totalmente lê assim. Ele ta executando todos os sctrls de vez, por isso que, o changestate direto para var(5) algumas vezes irá interferir no sctrl de varset pois se realmente lesse do jeito que vc taria colocando, ele ja daria erro antes de entrar a luta pq ele taria lendo o trigger2 primeiro pra depois o trigger3 e depois o trigger1. e mesmo vc colocando em ordem bagunçada ele lê em ordem crescente.
Sobre seu char, a comunidade mugen não é como antigamente então nem dê atenção a prêmios, tem pessoa que julga seu char mal justamente pq quebra a sincronia dos chars que gostam sendo que o chars que gostam tendem a ser op.
Meus chars tem AI simples que se auto adapta baseado no inimigo e alguns não gostaram pq a minha AI cancela as centenas de combo direto que programaram no char. Basicamente me dizendo que "meu char é ruim pq ele não deixa o char que gostam terminar os trocentos combo chain que possuem" kkkk.
Até minha AI é adaptada para esse crouch attack + especial que mencionei anteriormente. Quando sente que a outra AI ta sendo cheap ela "encerra" a AI inimiga por um super curto tempo pra deixar essa apelação.
Acho que eu ja tive seu robocop anos atrás, mas vou dar uma olhada no site.
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pm
Board: International
Agradeço humildemente por me elucidar e vou incluir essa sugestão daqui pra frente (também vou ignorar seu "75-75/5=0", pois divisão e multiplicação tem prioridade sobre soma e subtração, exceto se condicionar com parenteses).
Ah sim, essa parte eu não adcionei parêntesis no local certo, então me desculpe. Pelo menos você pegou a idéia. Se vc fosse testar (75-Var(13))/5 sendo var 13 = 75 note que no primeiro golpe do round mesmo se vc tiver continuo set de var 13 pra 75 o hitdef ainda vai tirar dano pq o jogo não lê o primeiro golpe.
Sobre os redirect de cond que eu, david11 e wolf desenlvolvemos é como se fosse algo assim:
Isso é uma parte do código usado pra o Genjutsu de Escuridão Infinita do Tobirama:
Code: Enemy,Cond(NumPartner,(Partner,Cond((SysVar(4)=1), Cond(NumExplod(30019)=0, Cond(Var(38):=3,0,0) ,0) ,0)) ,0)
Ou seja, eu estou olhando o que tem nos arquivos do p4 e setando a var(38) dele pra 3 mesmo não tendo tocado no p4 tudo isso em uma linha
eu recomendo pra NUNCA seguir completamente os docs do mugen pq nem mesmo eles sabem o que fizeram na engine.
Lembra que nos docs do trigger do mugen fala que redirecionamento recursivo não funfa e eles até deram um exemplo de "root,target,time"?
Nem mesmo os donos sabem como a engine funciona pq sempre foi possivel fazer mais de dois redirecionamento recursivo desde que lançaram o mugen 1.0, e isso é com o cond:
Code: Root,Cond(NumTarget,(Target, Cond(1,time,0)),0)
Isso o que eu acabei de escrever é a recursiva que a elecbyte disse que era impossivel de fazer.
Tenho certeza de que você(s) tem razão, mas quando comecei meu projeto não havia ainda aquele hack para jogar com times de 3 ou 4 personagens no Mugen 1.1b1 ! Uma das minhas metas era atualizar o Tag-team para esse número de personagens para ficar mais divertido. Mas não queria jogar fora o recurso de zoom de tela que dá mais dinamismo nas lutas à distância. Então tentei fazer os chars compatíveis, quando possível, com ambas as versões. Até que consigo bem nos chars (e para os cenários está sendo um desafio), mas o recurso de rotacionar os sprites só pelo arquivo AIR é uma elegância que sinceramente sinto falta!
Eu sinceramente não uso ferramentas de terceiros, principalmente o 3v3 ou 4v4. Mugen já é uma bagunça e eu usando isso seria quebrar os limites da intolerancia e apenas alimentar ainda mais os malfeitos no mugen. Outra coisa é que não precisa ter um Sctrl TeamTag pra fazer um team tag. Eu posso facilmente criar um que fique exatamente como essas ferramentas fazem e que tenha suporte universal. A questão é que essa ferramenta está editada na engine. Se eu realmente fosse usar ferramentas alternativas eu iria era mover do mugen pra outra coisa melhor. Tanto que até o WolfStak ta criando sua própria engine de luta https://www.youtube.com/watch?v=7ZvRvq27j2k
Ele vai basicamente misturar mugen e openbor em uma só engine, codificada em LUA
Code: [State -1, Jump Light Kick]
type = ChangeState
value = 631
triggerall = command = "a" && statetype = A && var(3) < 3
trigger1 = ctrl
ignorehitpause=1
;---------------------------------------------------------------------------
; auto - light
[Statedef 631]
type = U
[State 631, 1]
type = varSet
trigger1 = 1
v = 5
value = 630
[State 631, 2]
type = ChangeState
trigger1 = 1
value = 700
;---------------------------------------------------------------------------
; núcleo da conta: golpes X A.I.
[Statedef 700]
type = U
; Aqui um exemplo de discordância: se fora do alcance, mudar para outro hiper mais adequado
; A idéiaoriginal é o helper avaliar as coisas e escrever nas variáveis de var(30) à Var(39) do char principal as sugestões melhores, mudando a var(5) de acordo.
[State 700, 1]
type = Varset
triggerall = var(5) = 4000
trigger2 = enemy, pos y < 0 && p2bodydist x > 0
trigger3 = p2stateno >= fvar(6) && p2stateno <= fvar(7)
trigger1 = enemynear, stateno >= fvar(6) && enemynear, stateno <= fvar(7)
v = 5
value = 3000
ignorehitpause=1
[State 700, 2]
type = ChangeState
trigger1 = 1
value = var(5)
Sobre esse code que você botou, nem precisa totalmente gambiarra toda. Pelo oq tou vendo vc estar redirecionando o char pra um state vazio onde seta var(5) pra 630 e outro que modifica essa var pra pensar 2 vezes baseado em condiçoes. Primeiro vou apontar os "erros":
1- enemynear se redireciona a inimigos mortos entao ele vai considerar tbm aquele inimigo morto perto de vc. Vc então teria que adcionar duas condiçoes pra enemy(0) (p2) e enemy(1) (p4), checar se estao vivos e tentar redirecionar para o que vc quer. outra coisa que, helper player não é detectado pelo enemynear ou enemy entao um helper que vc está mirando nele por ele ser player seu code ficaria confuso para o p1 em termos de executar. O que basicamente ta fixado no seu trigger2 entao vc nao precisaria muito do trigger1
2- trigger2 = enemy, pos y < 0 && p2bodydist x > 0. Como eu te expliquei antes, enemy nao funciona em helper player mas p2bodydist/p2dist funciona entao se tivesse um helper player no meio dos dois vc taria redirecionando a pos Y do p2/p4 e a pos X do helper.
eu só não entendo esses trigger1 = 1. No statedef 700 pq por exemplo vc automaticamente entraria no changestate pq vc ta sempre executando, não daria nem tempo toda vez pra a var calcular o que ta havendo. e ambos statedefs podem ser resumidos em 1:
Code: [Statedef 631]
type = U
[State 631, 1]
type = VarSet
Trigger1 = !Time && ((Var(5)<4000)||(Var(5)>4000))
trigger2 = ((EnemyNear(0), StateNo >= FVar(6)) && (EnemyNear(0), StateNo <= FVar(7))) && (Time > 1) && (Var(5) = 4000)
trigger3 = Enemy,NumPartner>0
trigger3 = ((EnemyNear(1), StateNo >= FVar(6)) && (EnemyNear(1), StateNo <= FVar(7))) && (Time > 1) && (Var(5) = 4000)
trigger4 = (P2Dist Y < 0 && P2Dist x > 0) && (Time > 1) && (Var(5) = 4000)
trigger5 = (P2StateNo >= FVar(6)) && (P2StateNo <= fvar(7)) && (Time > 1) && (Var(5) = 4000)
v = 5
value = Cond((Time<1),630,3000)
[State 700, 2]
type = ChangeState
trigger1 = Time > 2
value = var(5)
Como eu estou usando codes separados pra p2 e p4 note que eu não precisei por a condiçao de detectar eles vivos, mas acho que ainda assim iria ser desnecessário esse trigger5. Como eu não tenho seu char e não faço a minima idéia como ele atua não sei se esse code totalmente iria servir, mas a lógica dele está correta.
Mas ao invés de usar seus poderes para o mal, isso pode ser uma contribuição
correto. Tanto que o povo pensa que se livrou do null glitch do winmugen mas estão enganados, ele ainda existe mas não como null e fico feliz que ninguem o encontrou até hoje.
lembra que eu mencionei que eu posso facilmente codificar um char usando a AI padrao do mugen, sem hitkill sem dano sem nada e ainda sim ganhar de todos os chars? Isso pq eu sei como anular seus wins que o mugen te da ou seja esse meu char iria apanhar bem feio mas vc nunca iria ganhar um round. Ja fiquei no round 15 testando esse code e o contador de win era 0 XD.
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pm
Board: International
Sim, AtkMulSet e DefMulSet são outros sctrls "bugados" pq na vdd o problema não ta neles e sim na engine.
Como eu falei, o mugen não detecta o primeiro golpe do round como hit verdadeiro e isso ainda piora pra esses dois SCTRLS pq cada primeiro golpe que vc da pode ou não ser lido pelo MulSets, basicamente dando aquele resultado de "ele só funciona quando quer no primeiro hit de cada atk". Mugen ainda tem o 1 tick lag que faz com que todos os triggers e sctrl "quebrem" aleatoriamente é por causa desse 1 tick lag que o trigger Time é algumas vezes lido como -1, 1, 2, 3[...]. Motivo que eu uso trigger1 = Time = 1 em certas ocasiões já que eu entendi pela maior part como esse 1 tick lag atua.
Outro motivo pra eu aprimorar a lida de código no -1, -2 e -3 pq o mugen a cada tick (ou seja em 0.016 segundos) tenta ler todo o conteúdo desses 3 que acaba causando delay dependendo do seu FPS ou do problema do 1 tick lag.
Por exemplo no -2:
[State -2]
Type = RemoveExplod
Trigger1 = StateNo != X
ID = 1234
IgnoreHitPause = 1
Veja que o explod se remove se o player não está em certo statedef. Mas isso significa que o removeexplod vai CONTINUAMENTE estar executando mesmo sem o explod existir porque vc o programou assim. Um melhor jeito de dar menos "stress" ao mugen seria:
[State -2]
Type = RemoveExplod
TriggerAll = NumExplod(1234)> 0
Trigger1 = StateNo != X
ID = 1234
IgnoreHitPause = 1
Significa que vc não vai estar ordenando ao mugen executar esse SCTRL a CADA TICK, mesmo o explod não existindo, pois desse segundo modo ele só executa se o explod existir.
Mugen 1.0 é usando DirectX enquanto o 1.1 é usando OpenGL 2.0+ o que é muito superior que o directX
Eu sugiro a vc tentar um pouco do 1.1 e vc vai ver o quão fluído ele é melhor que o 1.0. As vantagens do 1.1 sobre o 1.0 que eu mais gostei:
1- 1.0 primeiro lê a sprite com a escala original pra depois ler ela diminuída com o code que vc colocou, o que causa lag em certos efeitos gigantes.
2- 1.0 causa super lag se vc invocar projectiles ou helpers contínuos em um curto espaço de tempo, pois como é directX, requer mais da sua RAM já que o mugen foi feito de um modo estranho: ele usa diretamente sua ram pra tudo que ele faz.
Isso não acontece no 1.1. Mas primeiro veja se seu PC ta suportando de boa o OpenGL 2.0. Vc não precisa mudar nada nos seus chars 1.0 pra 1.1 
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pm
Board: International
Mugen se tornou sinonimo de coisas má programadas, péssimo gosto e balanceamento, o que é ruim.
Justamente isso. Como geralmente mugen é compilaçao de char vc percebe que em um jogo compilado várias coisas não funfam do jeito que deveria pq existem diferentes balanceamentos.
Outra coisa que não gosto é como automatizam AI: partir pra cima do inimigo e pressionar ele sem ter uma chance de recuperar ou pausa não é desafio, é na vdd preguiça de praticar o "trial and error". Existem varios AI patches que recentemente sempre usam crouch attack pq justamente sabem que Player não faz muito crouch guard e linkam esse crouch attack com uma pancada de especial e paradas de tela. Quando vc coloca um especial depois de um crouch attack vc está intencionado a fazer o special ser unguardable e isso é uma péssima mania e também um enorme desbalanceamento em quesito desenvolvimento.
Nas minhas AI por exemplo, elas recuam e sabem a hora de parar de te pressionar. Dois pontos importantes é que: primeiro é que A minha AI quando sente que vc ta indo apelão pra cima dela ela instantaneamente quebra seu combo, porque não era pra vc fazer esse combo cheap em um jogo de luta. Segundo que eu não jogo ela pra cima do alvo pra dar o MESMO combo chain, ela pode usar qualquer sequencia chain que ela bem entender e vai parar de te bater se passou do limite sano em bater. Tanto que até chars basicos meus conseguem enfrentar cheap AI melhor doq outros próprios cheap AI sem precisar ir no caminho mais rapido de "socar socar" em vez de ir pro logico que é estratégico.
Eu uso ifelse e não tenho problema nenhum com isso. Não acho bizarro, na verdade acho muito útil e intuitivo. Nunca tive um ifelse bugado, então talvez seja a maneira como voce ultiliza.
Todos os triggers e sctrl funcionam, mas ao mesmo tempo não funcionam. Eu posso até dizer as falhas que triggers como Time, TeamMode e sctrls assertspecial entre outros possuem. Mas como o foco é IfElse é um ifstatements mal feito pela elecbyte tanto que ela mudou pra o Cond e todo mundo deveria usar o cond. Ifelse faz com que tudo o que vc escreveu nele seja detectado como TRUE pra depois ele analizar o que é TRUE e o que é FALSE. Então vc pode ter seu ifelse as vezes executando algo FALSE que deveria ter executado TRUE. Já com cond ele não lê a linha direto que nem um "retardado" ele ja diz o que é true e o que é false.
Time no mugen a gente pensa que começa com 0, 1, 2, 3 [...] certo? O que realmente acontece, porém o mugen as vezes lê o Time como -1, 1, 2, 3. Em vez de começar com 0 ele lê tempo negativo (wtf) e pula o zero. Isso faz com que algumas vezes "!Time" e "Time =0" sejam triggers diferentes.
No assertspecial, todo o assert é desativado se houver algum Pause ou SuperPause a não ser que o Assert seja contínuo pq da refresh a cada tick.
Codificar com IfElse, pelo menos no meu modo de ver, é como se você quisesse criar um jogo na plataforma flash: enquanto vai fazer sucesso e funcionando vc tbm tem que perceber que flash vai morrer em 2020, basicamente codificando algo bom porém nos tempos das cavernas.
O hitdef que nosso amigo ali escreveu:
damage= 75-var(13)/5,0
O primeiro hit de todo o round, se esse hitdef for o primeiro "First Attack" SEMPRE dará dano 15, mesmo que vc tenha var(13) com valor 75 (o que na matemática daria 0 de dano) isso porque o primeiro hit do round não é lido pelo mugen. Vou até sugerir pra nosso amigo desse hitdef ai usar Floor(75-Var(13)/5) por causa de possivel dano decimal o que daria erro no debug.
.[State 4015, SprPriority]
type = SprPriority
trigger1 = ceil(var(7))=0
value = -3 ; <=========== aqui entra no layer -3 ao var(7) chegar à zero (um contador improvisado).
;ignorehitpause =
;persistent = 0
Eu só não sei o pq vc usou Ceil(var(7)) se Var é sempre número inteiro a não ser que seu calculo nessa var está dando valor decimal. Como vc está sempre executando esse trigger e hitdef com !movecontact executa apenas uma vez é normal esse SprPriority estar sendo executado a todo tick, ignorando seu hitdef, pois ele está sempre ativo.
. Sacanagem. Eu posto uma dúvida de Mugen e você joga o assunto para Java? Se isso não for um comando de Mugen, estarei decepcionado contigo.
Então amigo, foi o motivo que eu "subitamente" apareci por aqui, essa gambiarra que ele menciona foi justamente o que falei ali em cima. Como eu, David11 e Wolf usavamos Cond por anos descobrimos que com Cond dá pra fazer dezenas de redirecionamento apenas usando 1 linha mas não havíamos revelado para a comunidade até recentemente. Tanto que se eu quiser, posso até criar um char que seja o maior cheap char de todos e isso com AI default do mugen pois, eu consigo manipular aquelas medalhas de quantidade de vitória que vc ganha então um simples char poderia derrotar TUDO que as pessoas criaram até hoje pq se vc ganhar o round na vdd o mugen não te da a vitória e então qualquer cheap char cairia em um loop eterno de rounds pq todo o round seria tratado como "Round 1" e por causa disso é muito tosco ver pessoas com potenciais oculto por ai fazendo chars de mugen usando o caminho cheap achando que seu char ta bom e com isso essas pessoas acabam nem conhecendo a própria engine mesmo não sendo um novato no mugen.
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pm
Board: International
Vcs viram a gambiarra que dá pra fazer com o Cond? Tipo multiplos redirecionamentos?
Sim, na verdade quem descobriu isso foi WolfStak, David11 e eu quando estávamos vendo várias coisas no mugen. Fizemos diversos testes por mais de 1 ano e apenas revelamos pra as pessoas recentemente (motivo que explicarei embaixo). Existem varias coisas que descobrimos que não vejo o porque eu mencionaria (tem coisas que é bom ficarem enterradas) mas achamos melhor apenas revelar essa por enquanto por fazer vcs diminuirem a quantidade de código usado ja que pra um programador, resumir as coisas em código é tbm um ponto importante. No teste eu fiz 18 redirecionamentos utilizando apenas 1 linha com cond.
Ainda tem gente que usa ifelse e isso é muito bizarro então pra deixar as pessoas empolgadas com Cond decidimos revelar pra deixarem de usar esse maldito ifelse bugado que deveria ter morrido há 20 anos atrás.
Sobre o sprpriority tem coisas já codificadas na engine que da overwrite no sprpriority anterior, e até mesmo no próprio statedef mencionado pelo lord-s pq tudo é uma template, mesmo se vc não inclui a função, o parâmetro tem seu valor default consigo.
Ontop, é um valor universal, mas pelo o que eu entendi da engine é aleatório quem vai ficar na frente mas geralmente quem foi invocado depois fica na frente do anterior. Ontop ignora sprpriority então é bem bizarro ver as pessoas juntando os dois como se sprpriority maior em 2 ontop ficaria o maior na frente.
Outra coisa bem tensa em ver é quando a pessoa usa pause/supermovetime = 999999999. Isso é tipo HORAS de imunidade a pause e o round não dura horas kkk.
David eu e Wolf somos bem antigo mesmo no mugen mas vivíamos mais em foruns ucoz agora que isso passou de moda a gente ta se espalhando por aí.
Page 1 of 11
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pmBoard: International
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pmBoard: International
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pmBoard: International
. Espero que goste!
. Aliás, eu também queria ver seus chars, mas no seu perfil daqui não tem o endereço do seu site. Onde posso baixar?
No momento eu estou dando uma breve Att de HUD pra eles com certas novas mecânicas, então quando eu os lançar aviso. Porém meu estilo de char é de arte antiga, como eu apenas no momento gosto de codificar apenas naruto (como vc viu me mencionar o código do genjutsu da escuridão infinita) porém meus chars são do estilo SND (então é uma coisa bem antiga mesmo) que geralmente as pessoas não gostam muito pelo tamanho. Talvez por isso fiquei mais nos sites Ucoz em vez de forums grandes como esse nesse tempo todo.
Eu discordo totalmente. Se é algo que pode ser benéfico (mesmo que seja um erro), deve ser compartilhado. Existem pouquíssimas informações que não devem ser compartilhadas, mas não vejo o Mugen como um caso desses.O exemplo do Cond foi que, depois de mais de 10 anos as pessoas continuam usando ainda o IfElse, não que o Ifelse está totalmente errado (mas a lógica de como ele lê parcialmente está errado) mas é como eu falei com o amigo ali usando um exemplo de game em Flash Player: o game ainda vai ser topzão porém doq adianta usar uma lógica tão antiga ao ponto de ja estar morrendo? É tipo essas templates de mecânica que tem por aí que enche pra caramba seu -2 ou -3 sendo que na vdd vc poderia fazer o mesmo código com 20% do tamanho.
A única coisa que explica o uso de IfElse é: ou a pessoa está apenas sobrevivendo de templates, ou não liga muito ja que tudo funciona, ou simplesmente que nem vc falou no final: apenas quer tudo dado nas mãos sem fazer esforço.
Motivo que, depois de mais de 1 década que o Cond atua assim e ninguem percebeu pq cond foi ignorado, a gente acabou revelando.
O que eu falei sobre "há coisas que devem ficar enterradas" são coisas que se reveladas apenas vai evoluir esse câncer tóxico da comunidade mugen que vc mesmo mencionou. Eu sei muito bem que OpenBor é pequeno, mas o ponto sempre foi qualidade acima de quantidade e não o contrário.
Exemplos de coisas que não vou ensinar como faz:
Eu posso bloquear todo o seu -1 (CMD) do seu char, então vc não iria fazer exatamente NADA;
Eu posso simplesmente negar toda a sua AI baseada em p2dist ou até mesmo impedir que ela detecte que eu estou atacando ou que foi acertada por um ataque (pra caso que exista counter) ou até mesmo como falei pra o amigo ali, criar um char que não tenha Hitko e usando a AI default do mugen que poderia derrotar tudo, até mesmo os cheapie do winmugen. Mas ai está a questão: mugen virou um circo de coisa tosca, hentai e vore que se eu realmente fosse a Elecbyte ja mudaria o stats da engine pra abandonware. Até da pra perceber pq eles não tão nem aí mais pq eles não tão inativos, estão trabalhando em outras coisas nada relacionado a game. Então se eu ensinasse isso o mugen iria ficar pior ainda (o que a gente pensa que não pode ficar mais pior, mas acaba ficando...)
Outro ponto que discordo. Vc pode argumentar que seria melhor terem vários níveis de AI, de maneira progressiva, etc. Mas argumentar que ela não deveria pressionar sem dar uma change de recuperar me parece bastante equivocado, pq derroto o propósito de se ter uma AI.
No meu entendimento, ela deve te pressionar o tempo todo - pq eu mesmo jogo assim. Só paro de pressionar se eu achar que o risco não vale a pena. E esse é um ponto que eu deixo em aberto nas minhas AIs, para que seja explorado de propósito.
Isso na verdade depende da interpretação de quem está no comando. Inteligência Artificial na minha opinião não é ir pra cima "que nem um macaco raivoso gritando pra garantir win" pq aí vai contra o significado de INTELIGÊNCIA Artificial. É saber interagir como se fosse um player real. A questão é que muita gente só fica contente se a AI do char derrotar todo mundo e isso tbm não é significado da AI ou se o char estar bom (o que garante uma evolução se vc oferecer um feedback racional). Codificar por níveis pra mim é o correto (ou seja, o intervalo de parar de pressionar tbm depende da dificuldade, mas DEVE ter um intervalo que vc pare de pressionar e isso nunca vai significa que sua ai é ruim, ela só é estratégica ao ponto de o inimigo não se entediar fácil e não querer o char).
Porém esses debates fazem um conhecer melhor o outro e saber o que cada um faz já que ninguem aqui tá dizendo que o outro está errado (discordar de pontos tbm não significa isso)
Vou te dar um exemplo do seu Enke. Meu char não usa esses tipos de AI que vai pra cima com tudo usando chuva de combo (porém ele tbm não é burro, duh), mas ele se adapta a SUA AI, como o seu Enker é um tipo que pressiona constantemente o char, ele mesmo acaba perdendo por causa do seu próprio AI, é como se minha AI simplesmente "absorvesse sua AI e se tornasse melhor que ela". Por isso que desenvolvi uma AI assim, e ela está relacionado a dificuldade do jogo + ao mesmo tempo se adapta com outras AI ou seja, quando é contra player, ela age normal baseado na dificuldade a não ser que vc vire apelativo. Quanto mais chain combo vc spammar em tempos que são detectados como "já está apelando sem necessidade", vai acabar sendo derrotada.
Porém não significa que meus chars vão "absorver a AI inimiga" e sempre vencer, eles já perderam pra certas AI tão estupidas que até eu me surpreendi mas tbm não modifiquei nada pq ja demonstra que se adaptam contra tudo e não fazem o combate ser "injusto"
Posso usar inclusive o Mugen como exemplo: muita gente tem mania de compactar vários triggers na mesma linha, como se isso fosse "otimizar" a programação. Quando, de fato tem o efeito contrário (é um hábito ruim que se pega quando se aprende a programa com mugen). Se um triggerall precisa ser cumprido, ele deve ficar isolado na linha.Isso eu concordo com você por ser Triggerall
. E como vc pode ver, eu não compactei triggerall, mas eu esqueci de apontar esse detalhe em não colocar no triggerall.Vc é macaco velho e já sabe de cor e salteado essa máxima aqui: vc faz as coisas PRA VC e quem tem que gostar é VC. Vc disponibiliza para quem quiser usar, mas o foco foi, originalmente, vc. Feedback é sempre bem-vindo, para que todos possam fazer as coisas da melhor maneira possível. Mas muita gente pegou a mania de achar que todo mundo tem que fazer algo do jeito que acham que é e tudo que não for feito dentro daquele padrão "não presta".
Isso é outro ponto ultra importante, mas não pra o "seu Eu codificador" e sim pra o "seu eu psicológico". Hoje em dia existe muita gente gostando de personagens que, mecanicamente é estranho e tem outras que gostam. Muita gente ja ignora o char no roster justamente por causa do estilo de arte (o que é irônico pq os jogos mais icônicos não tem arte boa) ou até mesmo amostra falhas que não gostaram sendo que os personagens que gostam TAMBÉM tem essas falhas mas tem aquela leve iludida por causa que é um char que gosta vs um char que não gosta ou nunca ouviu falar. O char você está criando do seu coração, mugen é muito simples, mas também não significa que vc vire escravo de outra pessoa.
Feedback racional tbm ajuda muito o desenvolvimento. Um feedback dizendo que "não gostei pq bla bla" mas de um modo que vc percebe que o problema ta na pessoa então vc realmente n vai levar a sério.
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pmBoard: International
. Execução imediata. Por isso o "ChangeState" é o último item. Não tenho como confirmar que isso tem mais prioridade do que o "time = 0", mas é a impressão que me dá.
Normalmente a gente trata como se o mugen lesse tudo na ordem que a gente coloca, o que realmente acontece, ele lê de cima para baixo mas não totalmente lê assim. Ele ta executando todos os sctrls de vez, por isso que, o changestate direto para var(5) algumas vezes irá interferir no sctrl de varset pois se realmente lesse do jeito que vc taria colocando, ele ja daria erro antes de entrar a luta pq ele taria lendo o trigger2 primeiro pra depois o trigger3 e depois o trigger1. e mesmo vc colocando em ordem bagunçada ele lê em ordem crescente.
Sobre seu char, a comunidade mugen não é como antigamente então nem dê atenção a prêmios, tem pessoa que julga seu char mal justamente pq quebra a sincronia dos chars que gostam sendo que o chars que gostam tendem a ser op.
Meus chars tem AI simples que se auto adapta baseado no inimigo e alguns não gostaram pq a minha AI cancela as centenas de combo direto que programaram no char. Basicamente me dizendo que "meu char é ruim pq ele não deixa o char que gostam terminar os trocentos combo chain que possuem" kkkk.
Até minha AI é adaptada para esse crouch attack + especial que mencionei anteriormente. Quando sente que a outra AI ta sendo cheap ela "encerra" a AI inimiga por um super curto tempo pra deixar essa apelação.
Acho que eu ja tive seu robocop anos atrás, mas vou dar uma olhada no site.
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pmBoard: International
Agradeço humildemente por me elucidar e vou incluir essa sugestão daqui pra frente (também vou ignorar seu "75-75/5=0", pois divisão e multiplicação tem prioridade sobre soma e subtração, exceto se condicionar com parenteses).
Ah sim, essa parte eu não adcionei parêntesis no local certo, então me desculpe. Pelo menos você pegou a idéia. Se vc fosse testar (75-Var(13))/5 sendo var 13 = 75 note que no primeiro golpe do round mesmo se vc tiver continuo set de var 13 pra 75 o hitdef ainda vai tirar dano pq o jogo não lê o primeiro golpe.
Sobre os redirect de cond que eu, david11 e wolf desenlvolvemos é como se fosse algo assim:
Isso é uma parte do código usado pra o Genjutsu de Escuridão Infinita do Tobirama:
Code:
Enemy,Cond(NumPartner,(Partner,Cond((SysVar(4)=1), Cond(NumExplod(30019)=0, Cond(Var(38):=3,0,0) ,0) ,0)) ,0)
Ou seja, eu estou olhando o que tem nos arquivos do p4 e setando a var(38) dele pra 3 mesmo não tendo tocado no p4 tudo isso em uma linha
eu recomendo pra NUNCA seguir completamente os docs do mugen pq nem mesmo eles sabem o que fizeram na engine.
Lembra que nos docs do trigger do mugen fala que redirecionamento recursivo não funfa e eles até deram um exemplo de "root,target,time"?
Nem mesmo os donos sabem como a engine funciona pq sempre foi possivel fazer mais de dois redirecionamento recursivo desde que lançaram o mugen 1.0, e isso é com o cond:
Code:
Root,Cond(NumTarget,(Target, Cond(1,time,0)),0)
Isso o que eu acabei de escrever é a recursiva que a elecbyte disse que era impossivel de fazer.
Tenho certeza de que você(s) tem razão, mas quando comecei meu projeto não havia ainda aquele hack para jogar com times de 3 ou 4 personagens no Mugen 1.1b1 ! Uma das minhas metas era atualizar o Tag-team para esse número de personagens para ficar mais divertido. Mas não queria jogar fora o recurso de zoom de tela que dá mais dinamismo nas lutas à distância. Então tentei fazer os chars compatíveis, quando possível, com ambas as versões. Até que consigo bem nos chars (e para os cenários está sendo um desafio), mas o recurso de rotacionar os sprites só pelo arquivo AIR é uma elegância que sinceramente sinto falta!
Eu sinceramente não uso ferramentas de terceiros, principalmente o 3v3 ou 4v4. Mugen já é uma bagunça e eu usando isso seria quebrar os limites da intolerancia e apenas alimentar ainda mais os malfeitos no mugen. Outra coisa é que não precisa ter um Sctrl TeamTag pra fazer um team tag. Eu posso facilmente criar um que fique exatamente como essas ferramentas fazem e que tenha suporte universal. A questão é que essa ferramenta está editada na engine. Se eu realmente fosse usar ferramentas alternativas eu iria era mover do mugen pra outra coisa melhor. Tanto que até o WolfStak ta criando sua própria engine de luta https://www.youtube.com/watch?v=7ZvRvq27j2k
Ele vai basicamente misturar mugen e openbor em uma só engine, codificada em LUA
Code:
[State -1, Jump Light Kick]
type = ChangeState
value = 631
triggerall = command = "a" && statetype = A && var(3) < 3
trigger1 = ctrl
ignorehitpause=1
;---------------------------------------------------------------------------
; auto - light
[Statedef 631]
type = U
[State 631, 1]
type = varSet
trigger1 = 1
v = 5
value = 630
[State 631, 2]
type = ChangeState
trigger1 = 1
value = 700
;---------------------------------------------------------------------------
; núcleo da conta: golpes X A.I.
[Statedef 700]
type = U
; Aqui um exemplo de discordância: se fora do alcance, mudar para outro hiper mais adequado
; A idéiaoriginal é o helper avaliar as coisas e escrever nas variáveis de var(30) à Var(39) do char principal as sugestões melhores, mudando a var(5) de acordo.
[State 700, 1]
type = Varset
triggerall = var(5) = 4000
trigger2 = enemy, pos y < 0 && p2bodydist x > 0
trigger3 = p2stateno >= fvar(6) && p2stateno <= fvar(7)
trigger1 = enemynear, stateno >= fvar(6) && enemynear, stateno <= fvar(7)
v = 5
value = 3000
ignorehitpause=1
[State 700, 2]
type = ChangeState
trigger1 = 1
value = var(5)
Sobre esse code que você botou, nem precisa totalmente gambiarra toda. Pelo oq tou vendo vc estar redirecionando o char pra um state vazio onde seta var(5) pra 630 e outro que modifica essa var pra pensar 2 vezes baseado em condiçoes. Primeiro vou apontar os "erros":
1- enemynear se redireciona a inimigos mortos entao ele vai considerar tbm aquele inimigo morto perto de vc. Vc então teria que adcionar duas condiçoes pra enemy(0) (p2) e enemy(1) (p4), checar se estao vivos e tentar redirecionar para o que vc quer. outra coisa que, helper player não é detectado pelo enemynear ou enemy entao um helper que vc está mirando nele por ele ser player seu code ficaria confuso para o p1 em termos de executar. O que basicamente ta fixado no seu trigger2 entao vc nao precisaria muito do trigger1
2- trigger2 = enemy, pos y < 0 && p2bodydist x > 0. Como eu te expliquei antes, enemy nao funciona em helper player mas p2bodydist/p2dist funciona entao se tivesse um helper player no meio dos dois vc taria redirecionando a pos Y do p2/p4 e a pos X do helper.
eu só não entendo esses trigger1 = 1. No statedef 700 pq por exemplo vc automaticamente entraria no changestate pq vc ta sempre executando, não daria nem tempo toda vez pra a var calcular o que ta havendo. e ambos statedefs podem ser resumidos em 1:
Code:
[Statedef 631]
type = U
[State 631, 1]
type = VarSet
Trigger1 = !Time && ((Var(5)<4000)||(Var(5)>4000))
trigger2 = ((EnemyNear(0), StateNo >= FVar(6)) && (EnemyNear(0), StateNo <= FVar(7))) && (Time > 1) && (Var(5) = 4000)
trigger3 = Enemy,NumPartner>0
trigger3 = ((EnemyNear(1), StateNo >= FVar(6)) && (EnemyNear(1), StateNo <= FVar(7))) && (Time > 1) && (Var(5) = 4000)
trigger4 = (P2Dist Y < 0 && P2Dist x > 0) && (Time > 1) && (Var(5) = 4000)
trigger5 = (P2StateNo >= FVar(6)) && (P2StateNo <= fvar(7)) && (Time > 1) && (Var(5) = 4000)
v = 5
value = Cond((Time<1),630,3000)
[State 700, 2]
type = ChangeState
trigger1 = Time > 2
value = var(5)
Como eu estou usando codes separados pra p2 e p4 note que eu não precisei por a condiçao de detectar eles vivos, mas acho que ainda assim iria ser desnecessário esse trigger5. Como eu não tenho seu char e não faço a minima idéia como ele atua não sei se esse code totalmente iria servir, mas a lógica dele está correta.
Mas ao invés de usar seus poderes para o mal, isso pode ser uma contribuição
correto. Tanto que o povo pensa que se livrou do null glitch do winmugen mas estão enganados, ele ainda existe mas não como null e fico feliz que ninguem o encontrou até hoje.
lembra que eu mencionei que eu posso facilmente codificar um char usando a AI padrao do mugen, sem hitkill sem dano sem nada e ainda sim ganhar de todos os chars? Isso pq eu sei como anular seus wins que o mugen te da ou seja esse meu char iria apanhar bem feio mas vc nunca iria ganhar um round. Ja fiquei no round 15 testando esse code e o contador de win era 0 XD.
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pmBoard: International
Como eu falei, o mugen não detecta o primeiro golpe do round como hit verdadeiro e isso ainda piora pra esses dois SCTRLS pq cada primeiro golpe que vc da pode ou não ser lido pelo MulSets, basicamente dando aquele resultado de "ele só funciona quando quer no primeiro hit de cada atk". Mugen ainda tem o 1 tick lag que faz com que todos os triggers e sctrl "quebrem" aleatoriamente é por causa desse 1 tick lag que o trigger Time é algumas vezes lido como -1, 1, 2, 3[...]. Motivo que eu uso trigger1 = Time = 1 em certas ocasiões já que eu entendi pela maior part como esse 1 tick lag atua.
Outro motivo pra eu aprimorar a lida de código no -1, -2 e -3 pq o mugen a cada tick (ou seja em 0.016 segundos) tenta ler todo o conteúdo desses 3 que acaba causando delay dependendo do seu FPS ou do problema do 1 tick lag.
Por exemplo no -2:
[State -2]
Type = RemoveExplod
Trigger1 = StateNo != X
ID = 1234
IgnoreHitPause = 1
Veja que o explod se remove se o player não está em certo statedef. Mas isso significa que o removeexplod vai CONTINUAMENTE estar executando mesmo sem o explod existir porque vc o programou assim. Um melhor jeito de dar menos "stress" ao mugen seria:
[State -2]
Type = RemoveExplod
TriggerAll = NumExplod(1234)> 0
Trigger1 = StateNo != X
ID = 1234
IgnoreHitPause = 1
Significa que vc não vai estar ordenando ao mugen executar esse SCTRL a CADA TICK, mesmo o explod não existindo, pois desse segundo modo ele só executa se o explod existir.
Mugen 1.0 é usando DirectX enquanto o 1.1 é usando OpenGL 2.0+ o que é muito superior que o directX
Eu sugiro a vc tentar um pouco do 1.1 e vc vai ver o quão fluído ele é melhor que o 1.0. As vantagens do 1.1 sobre o 1.0 que eu mais gostei:
1- 1.0 primeiro lê a sprite com a escala original pra depois ler ela diminuída com o code que vc colocou, o que causa lag em certos efeitos gigantes.
2- 1.0 causa super lag se vc invocar projectiles ou helpers contínuos em um curto espaço de tempo, pois como é directX, requer mais da sua RAM já que o mugen foi feito de um modo estranho: ele usa diretamente sua ram pra tudo que ele faz.
Isso não acontece no 1.1. Mas primeiro veja se seu PC ta suportando de boa o OpenGL 2.0. Vc não precisa mudar nada nos seus chars 1.0 pra 1.1
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pmBoard: International
Mugen se tornou sinonimo de coisas má programadas, péssimo gosto e balanceamento, o que é ruim.Justamente isso. Como geralmente mugen é compilaçao de char vc percebe que em um jogo compilado várias coisas não funfam do jeito que deveria pq existem diferentes balanceamentos.
Outra coisa que não gosto é como automatizam AI: partir pra cima do inimigo e pressionar ele sem ter uma chance de recuperar ou pausa não é desafio, é na vdd preguiça de praticar o "trial and error". Existem varios AI patches que recentemente sempre usam crouch attack pq justamente sabem que Player não faz muito crouch guard e linkam esse crouch attack com uma pancada de especial e paradas de tela. Quando vc coloca um especial depois de um crouch attack vc está intencionado a fazer o special ser unguardable e isso é uma péssima mania e também um enorme desbalanceamento em quesito desenvolvimento.
Nas minhas AI por exemplo, elas recuam e sabem a hora de parar de te pressionar. Dois pontos importantes é que: primeiro é que A minha AI quando sente que vc ta indo apelão pra cima dela ela instantaneamente quebra seu combo, porque não era pra vc fazer esse combo cheap em um jogo de luta. Segundo que eu não jogo ela pra cima do alvo pra dar o MESMO combo chain, ela pode usar qualquer sequencia chain que ela bem entender e vai parar de te bater se passou do limite sano em bater. Tanto que até chars basicos meus conseguem enfrentar cheap AI melhor doq outros próprios cheap AI sem precisar ir no caminho mais rapido de "socar socar" em vez de ir pro logico que é estratégico.
Eu uso ifelse e não tenho problema nenhum com isso. Não acho bizarro, na verdade acho muito útil e intuitivo. Nunca tive um ifelse bugado, então talvez seja a maneira como voce ultiliza.
Todos os triggers e sctrl funcionam, mas ao mesmo tempo não funcionam. Eu posso até dizer as falhas que triggers como Time, TeamMode e sctrls assertspecial entre outros possuem. Mas como o foco é IfElse é um ifstatements mal feito pela elecbyte tanto que ela mudou pra o Cond e todo mundo deveria usar o cond. Ifelse faz com que tudo o que vc escreveu nele seja detectado como TRUE pra depois ele analizar o que é TRUE e o que é FALSE. Então vc pode ter seu ifelse as vezes executando algo FALSE que deveria ter executado TRUE. Já com cond ele não lê a linha direto que nem um "retardado" ele ja diz o que é true e o que é false.
Time no mugen a gente pensa que começa com 0, 1, 2, 3 [...] certo? O que realmente acontece, porém o mugen as vezes lê o Time como -1, 1, 2, 3. Em vez de começar com 0 ele lê tempo negativo (wtf) e pula o zero. Isso faz com que algumas vezes "!Time" e "Time =0" sejam triggers diferentes.
No assertspecial, todo o assert é desativado se houver algum Pause ou SuperPause a não ser que o Assert seja contínuo pq da refresh a cada tick.
Codificar com IfElse, pelo menos no meu modo de ver, é como se você quisesse criar um jogo na plataforma flash: enquanto vai fazer sucesso e funcionando vc tbm tem que perceber que flash vai morrer em 2020, basicamente codificando algo bom porém nos tempos das cavernas.
O hitdef que nosso amigo ali escreveu:
damage= 75-var(13)/5,0
O primeiro hit de todo o round, se esse hitdef for o primeiro "First Attack" SEMPRE dará dano 15, mesmo que vc tenha var(13) com valor 75 (o que na matemática daria 0 de dano) isso porque o primeiro hit do round não é lido pelo mugen. Vou até sugerir pra nosso amigo desse hitdef ai usar Floor(75-Var(13)/5) por causa de possivel dano decimal o que daria erro no debug.
.[State 4015, SprPriority]
type = SprPriority
trigger1 = ceil(var(7))=0
value = -3 ; <=========== aqui entra no layer -3 ao var(7) chegar à zero (um contador improvisado).
;ignorehitpause =
;persistent = 0
Eu só não sei o pq vc usou Ceil(var(7)) se Var é sempre número inteiro a não ser que seu calculo nessa var está dando valor decimal. Como vc está sempre executando esse trigger e hitdef com !movecontact executa apenas uma vez é normal esse SprPriority estar sendo executado a todo tick, ignorando seu hitdef, pois ele está sempre ativo.
. Sacanagem. Eu posto uma dúvida de Mugen e você joga o assunto para Java? Se isso não for um comando de Mugen, estarei decepcionado contigo.
Então amigo, foi o motivo que eu "subitamente" apareci por aqui, essa gambiarra que ele menciona foi justamente o que falei ali em cima. Como eu, David11 e Wolf usavamos Cond por anos descobrimos que com Cond dá pra fazer dezenas de redirecionamento apenas usando 1 linha mas não havíamos revelado para a comunidade até recentemente. Tanto que se eu quiser, posso até criar um char que seja o maior cheap char de todos e isso com AI default do mugen pois, eu consigo manipular aquelas medalhas de quantidade de vitória que vc ganha então um simples char poderia derrotar TUDO que as pessoas criaram até hoje pq se vc ganhar o round na vdd o mugen não te da a vitória e então qualquer cheap char cairia em um loop eterno de rounds pq todo o round seria tratado como "Round 1" e por causa disso é muito tosco ver pessoas com potenciais oculto por ai fazendo chars de mugen usando o caminho cheap achando que seu char ta bom e com isso essas pessoas acabam nem conhecendo a própria engine mesmo não sendo um novato no mugen.
Posted by MkTendou
in [PORTUGUESE ONLY] Português. Ena pá. (Started by LC-DDM August 27, 2007, 01:31:55 pmBoard: International
Vcs viram a gambiarra que dá pra fazer com o Cond? Tipo multiplos redirecionamentos?
Sim, na verdade quem descobriu isso foi WolfStak, David11 e eu quando estávamos vendo várias coisas no mugen. Fizemos diversos testes por mais de 1 ano e apenas revelamos pra as pessoas recentemente (motivo que explicarei embaixo). Existem varias coisas que descobrimos que não vejo o porque eu mencionaria (tem coisas que é bom ficarem enterradas) mas achamos melhor apenas revelar essa por enquanto por fazer vcs diminuirem a quantidade de código usado ja que pra um programador, resumir as coisas em código é tbm um ponto importante. No teste eu fiz 18 redirecionamentos utilizando apenas 1 linha com cond.
Ainda tem gente que usa ifelse e isso é muito bizarro então pra deixar as pessoas empolgadas com Cond decidimos revelar pra deixarem de usar esse maldito ifelse bugado que deveria ter morrido há 20 anos atrás.
Sobre o sprpriority tem coisas já codificadas na engine que da overwrite no sprpriority anterior, e até mesmo no próprio statedef mencionado pelo lord-s pq tudo é uma template, mesmo se vc não inclui a função, o parâmetro tem seu valor default consigo.
Ontop, é um valor universal, mas pelo o que eu entendi da engine é aleatório quem vai ficar na frente mas geralmente quem foi invocado depois fica na frente do anterior. Ontop ignora sprpriority então é bem bizarro ver as pessoas juntando os dois como se sprpriority maior em 2 ontop ficaria o maior na frente.
Outra coisa bem tensa em ver é quando a pessoa usa pause/supermovetime = 999999999. Isso é tipo HORAS de imunidade a pause e o round não dura horas kkk.
David eu e Wolf somos bem antigo mesmo no mugen mas vivíamos mais em foruns ucoz agora que isso passou de moda a gente ta se espalhando por aí.