Mugen Engine Bugs

[Seravy]

I have this code for the helpers :

[State 13911]
Type=Trans
trigger1=1
trans=add

[State 13911]
Type=Angledraw
trigger1=var(18)=0
scale=0.0125*time,0.0125*time

And they aren't transparent while var(18)=0. As soon as var(18) is 1, they become transparent.
Also tried putting the two in reverse order, and adding transparency to the animation in the air file. Neither worked. If it works for you, please post a working code and I'll try that.

[State 12901]
Type=ModifyExplod
Trigger1=time %600<480
ID=12901
scale=5,5
vel=10,10

This one makes the explods 5 times bigger, but their speed is unchanged. What is wrong with it,then? Please post a working code if it works for you.

[Rajaa Retired]

;---------------------------------------------------------------------------
;Ko'ouken
[Statedef 8005]
type=A
movetype=I
physics=N
ctrl=0
sprpriority=5
velset=0,0
anim=8005

[state 8000,Na_Chhaayaa]
type=assertspecial
trigger1=1
flag=noshadow
ignorehitpause=1

[state 8005,Damak]
type=trans
trigger1=1
trans=add
ignorehitpause=1

[state 8005,Akaar]
type=angledraw
trigger1=1
scale=1,1
ignorehitpause=1

[State 8000,Ajay]
type=nothitby
trigger1=1
value=SCA
time=5
ignorehitpause=1
persistent=1

[state 8000,Apne_Naash_Karna]
type=destroyself
trigger1=animtime=0

Works fine for me ???, i even rotated it just now to see if that made a difference and it still works.

[Seravy]

Thanks a lot, I managed to make it work. I found a stray trans controller in the later parts of the state, so the first one didn't matter, as the second one overrode it.
This calls for a revised #7...

#7 : A trans controller with addalpha and an angledraw with scale doesn't work together.

(The wrong code was :

[State 13911]
Type=Angledraw
trigger1=var(18)=0
scale=0.0125*time,0.0125*time

...

[State 13911]
Type = trans
Trigger1 = 1;*var(18)>0*
type = addalpha
alpha= 160+var(19)-var(1)*0.3,224-var(19)+var(1)*0.3
time = 1

and adding the var(18)>0 into the above one fixed it. (The other two variables were 0 so they didn't matter))

[Cyanide]

[State 12901]
Type=ModifyExplod
Trigger1=time %600<480
ID=12901
scale=5,5
vel=10,10

If the original explod creation has a -1 bindtime set that will stay in progress. Try a bindtime of 1 for the original creation instead.

[Seravy]

The original has a bindtime of 1, and a starting vel of 0,1, and is moving properly down 1 pixel/tick.
After the modify, it is still moving down at 1 pixel/tick, but is 5 times the size.

(The original code, it is a snowfall generating effect)
[State 7703]
Type=Explod
Trigger1=1
anim=10600
ID = 12901+random %3
Postype=left
pos= time %21*16,random %20-40
bindtime=1
removetime=240
ontop=1
vel=0,1
sprpriority=99
ownpal=1
scale= 1,1
Ignorehitpause=1
Pausemovetime=9999
Supermovetime=9999
Trans=add

[State 12901]
Type=ModifyExplod
Trigger1=time %600<480
ID=12901
;vel=1-2*((time/60)%2),1  (This was the intended code)
scale=5,5 (and these are for testing only)
vel=10,10 

(All ID=12901 explods are 5 times the size but move at a speed of 0,1...)

[Cyanide]

I think i managed to get them moving at 2, but couldn't get them to go at 10. I hate modifyexplod. 90% of the time when i use it it doesn't act as expected. You'd be better off using a few helpers and having them create lots of explods and then make the helpers move instead.

[Seravy]

Nice idea, I'll do that. Thanks.

[Seravy]

This probably doesn't count as a bug but also worth notice :
When you use hitoverride in a custom state they'll move the opponent back to their normal state just like SelfState does. Which is a pain when you need to make a custom state where the opponent needs to be hit and stay in the state afterward.

[Cyanide]

If you hit someone in a custom state you reuse p1 and p2stateno to change their state. Or emulate the hit and targetstate them instead.

[Seravy]

The pain comes from the fact that this is a magic spell that turns the opponent smaller, and any attack can be used on him while it lasts, so I had to add P2Stateno to all 100+hitdefs and projectiles in the character. It works fine, but this is yet another thing that could have been done with a single hitoverride if there were an option for staying in those states, and this way it requires 200+lines of code, an additional state, and an additional variable...
However I did found something strange...after adding P2StateNo to the attacks (and not changing anything else) I found that many attacks do no damage on chars with superarmor. I'm yet to test exactly which ones, because some do, some don't. (and never actually went against those before, so it might be another problem)

[Cyanide]

The pain comes from the fact that this is a magic spell that turns the opponent smaller, and any attack can be used on him while it lasts, so I had to add P2Stateno to all 100+hitdefs and projectiles in the character. It works fine, but this is yet another thing that could have been done with a single hitoverride if there were an option for staying in those states, and this way it requires 200+lines of code, an additional state, and an additional variable...
However I did found something strange...after adding P2StateNo to the attacks (and not changing anything else) I found that many attacks do no damage on chars with superarmor. I'm yet to test exactly which ones, because some do, some don't. (and never actually went against those before, so it might be another problem)

Mugen readme. Known faults

Players
-------
- No support for multiple palettes in players
- Helpers used as projectile replacements do not have all the desired
  properties of a projectile
- Collision boxes in helpers inherit parent's scale, regardless of own
  scale
- HitOverride controller always prevents player from being hit by
  attacks with a HitDef p2stateno parameter
- Stick-around helpers and explods get removed during intro skip

[Seravy]

Wow, this is a pretty huge bug, even if it's known.
Now what? Am I supposed to replace all 100+ hitdefs the character uses with projectiles? lol...that's a ton of work... Quite a lot of work for something that could have been solved white a simple stayinp2state option for hitoverride. I mean come on, Elecbyte could have added that option in a few minutes or at most hours...and every single person who needs to use it ends up having days of additional work.
The only "luck" is that projectiles do work properly even on hitoverride,unlike hitdefs.
Now...how am i supposed to do this? Unlike attack hitdefs, projectiles are not removed when the character is hit...and I don't see a removeprojectile sctrl unlike removeexplod. Eww...this'll be complicated.

[Seravy]

Another bug-like feature worth noting :

If your attack has a hitdef on the first tick (time=0) and a clsn box for it, that attack is unguardable, as the opponent won't have enough time to change into his defense state, but instead will be hit immediately. Also, if guard.dist is too low, the same happens, the opponent won't change into defense, and will be hit even if he is pressing the guard button, if I remember well.

And the one I found while making those projectiles : the Projcontact trigger doesn't seem to work when redirected.

[Cyanide]

If your attack has a hitdef on the first tick (time=0) and a clsn box for it, that attack is unguardable, as the opponent won't have enough time to change into his defense state, but instead will be hit immediately. Also, if guard.dist is too low, the same happens, the opponent won't change into defense, and will be hit even if he is pressing the guard button, if I remember well.

That one is known. And it's generally best to try and avoid it.

As for your p2stateno issue. Method 1. Find a method of identifying people with hitoverride and when it's active and use the hitdef parameter p2getp1state

Or remove it, and set up targetstates on movecontact which is a little more reliable and kills super armour.

[Seravy]

Back to the affectteam part :
Projectiles doesn't work together with affectteam. Probable reason is they are owned by the root even if helpers create them, and as we already know the root(or any player) cannot hit itself.

That one is known. And it's generally best to try and avoid it.

Known doesn't mean new coders automatically know it. I made this thread with the intention of collecting every single engine bug(or other stuff that works different from what you'd expect/is in the documentaion) in one place, so everyone can read all of them on the same place and avoid falling in these traps, when they start out.

As for your p2stateno issue. Method 1. Find a method of identifying people with hitoverride and when it's active and use the hitdef parameter p2getp1state

How do I know if my opponent has an active hitoverride or not? There is no such trigger I think.
Also, does this mean if P2GetP1State=0, then P2StateNo can do damage on a hitoverride properly, so the bug only applies to P2GetP1State=1?

hmm targetstate, never used it before. Does that put the opponent into my states or his? The documents say nothing about it.
Do you think a
[State -2]
Type=TargetState
Trigger1=1
StateNo=xxxx
could work?

Anyway I'm more than halfway done with replacing hitdefs with projectiles already.

[MikeDaBike]

hmm targetstate, never used it before. Does that put the opponent into my states or his? The documents say nothing about it.
Do you think a
[State -2]
Type=TargetState
Trigger1=1
StateNo=xxxx
could work?

Anyway I'm more than halfway done with replacing hitdefs with projectiles already.

It works exactly like p2stateno, it sends the target to YOUR state. To avoid warnings you got to check if you have a target though (trigger1 = numtarget).

[Seravy]

Good, then I'll try that method the next time I need to use it in a character. I rather finish this one the way I started.

I also tried defencemulset today, and it really doesn't work. I added

Code Select Expand


[State 5xxx]
Type=LifeAdd
Trigger1 = !IsHelper
Trigger2 = IsHelper(14400)
Value=floor(GetHitVar(damage)*fvar(14))
ignorehitpause=1

into states 5000,5010,5020,5070 and 5080  instead, where fvar(14) is one minus the value I used for defencemulset before.
Did I place it in all the correct state numbers? Am I correct in assuming the placing it in -2 would ignore multiple hits received at the same time, so they need to be in the 5xxx states?

[Cyanide]

Defencemulset is widely known to be horribly buggy in winmugen.

1) Only works on and beyond the second hit of a combo
2) 0.5 is actually double defence while 1.5 would be half, or something like that, it's screwed anyway.

Worked properly in dosmugen though but something broke in the transfer.

Remember, defencemulset and attackmulset are turned on/off. Once it's at a value it stays there.

[Seravy]

Latest discovery :
You go into your hit state as soon as you get hit, but you take the damage from it at the end of the tick only. However, mugen limits the damage of the attack to your life at the moment of the hit, so adding one life there will make you survive anything.

Example : You have 300 life, You are hit with an attack with damage=500. You get hit, the damage is changed to 300, you go into state 5000 (or whatever is appropriate), and at the end of the tick, after all code in state 5000 and the minus states were executed, your life is reduced by 300. Even if you happen to have 310 life by then, and the original attack did 500 damage.

[aokmaniac13]

Maybe I did something wrong here:
Bound explods with ignorehitpause = 0 don't follow their parent properly when the screen pans during a hitpause.