EoH/Project X Rogue

[Acey]

I just noticed something when you demonstrated Rogue's Power Drain on herself. The jacket Rogue loses said jacket when she's drained. And the jacket itself remained on the ground. What does this function serve?

Fake Answer - I just think it's cool that Rogue's coat can come flying off if she is hit hard enough, kind of like Vega's claw. Aren't I a genius?

Real answer - Mugen is a great, but imperfect system. It allows for a wide variety of compatibility amongst characters that are completely unrelated, you can plug and play all types of content and it will work together, however this does cause some problems...

Example 1 - Did you download Angel from CVG, notice every time you throw Archangel he is forced back into the Angel sprites for the duration of the throw.

Example 2 - Did you download Captain America by Mystic Blaze, in my opinion the most top notch coded character in mugen, hands down. But if you throw him his shield will either disappear or just bug out for a few frames.

See, whenever you have some kind of clever coding going on in your mugen character, like switching an entire sprite set, or a helper like Captain America's shield (and Rogue's coat for that matter), mugen won't be able to handle it when ever the character is put into a custom state (basically any state that is controlled by the opponents code rather than P1's code.) So what would have happened naturally to Rogue in the scenario is that every time she was thrown her coat would be all misaligned like crazy, most often even being one or two body distances away from her actually body. The solution to this is to make her coat fall off and hit the ground whenever she is forced into a custom state then allow the character to go pick it up later at the player's convenience. So I ask again, aren't I a genius?

But seriously, the real solution is all in Elecbyte's hands. Right now mugen can not use single sprites as a trigger, only animations or states. If we were able to use single sprites as a trigger then this problem could be completely avoided by the use of additional code.

[HyperVoiceActing]

Oh, I don't see it as a flaw. I think it's a cool little touch of detail.

And yes, you are a genius

[ZVitor]

and we are not talking only about thorws, some cheators use custom states to lot of things, exemple: sabaki psylocke hard punch or eoh launcher.

Acey did a great  solution to that problem, anyway it should work to fix cap shield, but not to angel/archangel mode.

[laspacho]

Maskless wolverine getting hit is a good example too.

[ZVitor]

Maskless wolverine getting hit is a good example too.

true, but wolverine turn between mask and unmask is not so big deal like angel/archangel

[O Ilusionista]

Example 1 - Did you download Angel from CVG, notice every time you throw Archangel he is forced back into the Angel sprites for the duration of the throw.

You can make a workaround to this, if you will make a closed game.

Example 2 - Did you download Captain America by Mystic Blaze, in my opinion the most top notch coded character in mugen, hands down. But if you throw him his shield will either disappear or just bug out for a few frames.

For me too. But I never understood why he doesn't made a fix to this, since is so easy.

There is a way to detect if you are on a custom state:

[1000, bla bla bla]
Type = VarSet
trigger1 = Stateno !=[5000,5999] && Stateno != [130,152] && MoveType = H
v = XX
Value = XX

Then the helper check it this is true and goes to the ground. You can make it without the var:

[1000, bla bla bla]
Type = ChangeState
TriggerAll = IsHelper(XXXX)
trigger1 = root,Stateno !=[5000,5999] && root,Stateno != [130,152] && root,MoveType = H
Value = XX

The logic is simple:
If the root is on a Hit state, the helper drops itself to the ground.
5000-5999 are hit states (I know that Mugen doesn't have the state 5999, but those numbers are reserved), 130-152 are block states (which are hit states) and moves with custom states SHOULD PUT P2 ON A "H" Movetype state.

But if the creator is lazy (like doesn't setting the movetype to H on the custom state) it will fail.

[Acey]

That codes leaves too much to chance actually. What if the custom hit state falls into one of those ! ranges, for example if someone made a custom electricity or freeze state and decided to put it into their 5000 series of statedef to coincide with the rest of their hit states.

Instead there is actually a very non intuitive was to make the character actually record the var when in and out of the custom get hit state using sctrls in both statedef -2 and statedef -3. Sludge is the one who figured it out and it is used in Arthur, Green Goblin, My Captain America and Rogu. It's flawless under any circumstance.

[HyperVoiceActing]

Sounds awesome.

That reminds me, I should probably practice with SC Rogue to prepare for this release (I kinda suck using her )

[Acey]

Good idea, but I should point out that SC Rogue is designed as a floating tank, so she has less combo ability and more resilience then the release will have.

[HyperVoiceActing]

Thanks for the tip 

[O Ilusionista]

What if the custom hit state falls into one of those ! ranges, for example if someone made a custom electricity or freeze state and decided to put it into their 5000 series of statedef to coincide with the rest of their hit states.

Its simple: you just adjust the ! range, its not that hard.

That range was to be generic, you can lower it to fit just Mugen actual hitstates.

For example, you can set it to the last Mugen's reserved state, 5210*

trigger1 = Stateno !=[5000,5210] && Stateno != [130,152] && MoveType = H

Now works perfectly. I will update the other topic

*I know about the 5900 state, but its not a H type.

And to use custom states with the normal MUGEN hit states numbers is something very dumb to make, If I can say.

[Acey]

I'm just saying there is a way to completely avoid using stateno triggers at all, and if you avoid that you will be able to avoid those bugs no matter what the other character's programmer set their statedefs as.

Code: [Select]

[statedef -2]

[State -2, VarSet] ;Char is in custom hit state
type = VarSet
trigger1 = var(22) = 1
v = 23
value = 1

[State -2, VarSet] ;set var if in -2
type = VarSet
trigger1 = var(22) = 0
v = 22
value = 1


[statedef -3]

[State -3, VarSet] ; set var if in -3
type = VarSet
trigger1 = 1
v = 22
value = 0

[statdef ##] ;wherever fits best in your char, typically helper lie dead state

type = ParentVarSet
trigger1 = (parent, var(23) = 1)
v = 23
value = 0


using var 22 and 23 above you use var 22 to determine if the character is in [statedef -2] or [statedef -3], where var(22) = 1 means self state and var(22) = 0 is not. But sticking with just this code would prove volatile in mugen so you need to have var(23) that assesses the value of var(22) which can then be used in your character code as a trigger. So by doing this in essence your trigger will be as follows

Code: [Select]

trigger1 = var(23) = 1 ;self state
trigger1 = var(23) = 0 ;not self state

And no messing with stateno or hoping the other character's programmer was smart enough to label their movetype properly as "H", because we know there are far too many characters out there that were programmed by novices who are still learning all the intricate details of character programming.

[O Ilusionista]

Yeah, I know. I'm not arguing.

But there will be a problem: p2 CAN READ your -2 codes (this is the main difference between -2 and -3), so you could overrite some of its vars. which would lead to some bugs. And you would need to fix that code to work with non-helpers chars.

Its a good code, but I think that this point + the use of 2 vars would make the code not so smart as the previous one.

hoping the other character's programmer was smart enough to label their movetype properly as "H", because we know there are far too many characters out there that were programmed by novices who are still learning all the intricate details of character programming.

I don't want to sound rude, but this sound as a excuse. And a bad one.

If a novice forget to put this, it should be adviced to fix his char.
But, for sure, is something SO EASY that just if he is too lazy he would forgot it.

[Acey]

If someone's characters is overriding your characters vars then that's a sign of much bigger problems. What is an example of where the opponent is supposed to be overriding your vars outside of a closed screen pack?

[O Ilusionista]

So...this render your code non-working, got it?

Think about:

no matter what the other character's programmer set their statedefs as.

That is absurd.
Hitstates MUST have the MoveType set as H, is a Mugen starndard.
Its totally nonsense someone using a I, for example, on a hitstate...just because the creator wants to or its novice.

This is something that always pissed me off: "oh the creator is novice".
And so what? Just because he is a novice...nobody can point him to the right direction?

What is an example of where the opponent is supposed to be overriding your vars outside of a closed screen pack?

To nullify your char AI, for example.

Sorry if I off-topic your post. Its not my intention.

[Acey]

No, the question was, "What is an example of where the opponent is supposed to be overriding your vars outside of a closed screen pack?"

[O Ilusionista]

As I replied at the previous post:

To nullify your char ai, for example.

And you don't got it: your code could override p2 own vars.

[Acey]

Ok, explain how you would nullify your opponents AI in statedef -2 please...

I can see why one would want to mess with var(1) for example, which is treated as a temp var in all the chars, but if you're messing with vars in the teens and higher then there's some serious issues.

[rednavi]

vars below 10 are temp vars? Who told you that? There are tons of characters who use vars below 10 for important stuff that must be read the whole time. And even if it's for temporal stuff it's still as important as the author of the char decides to.

And you don't got it: your code could override p2 own vars.

read this again. (Yeah, dont pay attention to his grammar mistake, it's nothing serious).

[Acey]

vars below 10 are temp vars? Who told you that? There are tons of characters who use vars below 10 for important stuff that must be read the whole time. And even if it's for temporal stuff it's still as important as the author of the char decides to.

read this again. (Yeah, dont pay attention to his grammar mistake, it's nothing serious).

Hey, I totally agree with you. I didn't say all vars below 10 are temp.

[rednavi]

and what's this about then?

I can see why one would want to mess with var(1) for example, which is treated as a temp var in all the chars, but if you're messing with vars in the teens and higher then there's some serious issues.

is this something related to a specific fullgame feature or something? I just dont get what you mean on this part.

[Acey]

and what's this about then?

is this something related to a specific fullgame feature or something? I just dont get what you mean on this part.

That statement was a consession to O Ilusionista, deviating from my point, the point of this specific statament was "ok, there may be a legit reason to override a variable but otherwise if would be foolish to program your character to override variables in another mugen character because the results would be disasterous." You are correct, not even half of the mugen programmers out there use var(1) as a temp var, making even this consession very weak one to begin with.

The discussion here is that O Ilu posted some code for state detection and I posted some code that I considered would be more reliable and O Ilu is makeing an argument as to why the code is not reliable at all. According to what O Ilu said, having a var in statedef -2 means that it can be overridden by P2. And I'm saying that's crazy, if someone programmed their characters to override your variables (ouside of a full game enivronment) then that is a broken character. I'm saying that using vars in statedef -2 and statedef -3 is a superior method of selfstate detection rather than depending on a variety of triggers that rely on the other coders competence, especially since we have all seen tons of characters pass through the walls of mugen who have their hitdef attributes coded poorly that goes unnoticed since its effects on game play is not immediatly noticable.

[Vinnie MUller]

É linda definitivamente. Principalmente todo o trabalho de editar o novo uniforme e usar a paleta inteligente. Porém como dito, está pronta passando pelos últimos retoques.
Pergunta: Foi só eu ou mais alguém se incomodou com o tom de marrom mais claro usado para diminuir a mecha branca de seus cabelos da versão anterior?

Ao mesmo tempo, também achei a parte branca que permaneceu, muito pequena em comparação com todo volume de cabelo que ela tem. Ou deveria diminuir o volume, ou (de preferencia e até mais fácil) dá uma pequena aumentada na mecha branca (a mecha dela parece dividida em gomos, talvez mais um desses já equilibraria)

Alguns dos super roubados, são mesmo o super do oponente, embora na maioria dos casos, só uma versão exe do special move. Uma pena, mas bastante compreensível devido o demasiado trabalho e acumulo de sprites.

Quando sugeri a rogue dual mode seria mais ou menos isso com a paleta inteligente, mas a paleta classica com os golpes clássicos da rogue voadora,super-forte com absorção e a paleta com uniforme novo, golpes todos baseados em ataques físicos e agarrões abusando de efeitos de seu poder original de absorção que é o único que ele possui , porém com admirável controle.

Cópia de golpe
Ampliação de barra de super
Ampliação de life
Ampliação de força/defesa/velocidade
Tontura no oponente (inverção do direcional)
Retirada de seus poderes (time bloqueando special e super move)
seus pupilos como helpers
Bolar oponete
esquivas

fazer uma versão nova, original, baseado nas capacidades e limitações de seus poderes básicos originais!!!

Uhúúúúú...amaria.

Quem sabe um dia!

Aguardo o lançamento desse sua jóia rara Acey!!!

abraços

[Arkady]

sooo?  sorry to get on topic.
i like the new smart pallet, are you going to use to palfx for specific characters ( like the one i sent you)  or is she just going to just mimic the moves
p.s. love the way her moves are in project x, very well done   

[Acey]

sooo?  sorry to get on topic.
i like the new smart pallet, are you going to use to palfx for specific characters ( like the one i sent you)  or is she just going to just mimic the moves
p.s. love the way her moves are in project x, very well done   

She will use a palfx for situations like iceman and human torch but that's about it.