Problems with a complicated hyper

[TrinitroRoy]

How long is anim 4205? If you change it to 0 (for testings sake) does the crash continue to occur?

I can't see a thing in the code that would cause an issue. I mean sprpriority isn't valid for a hitdef, but mugen's parser won't complain about that so i doubt that's the issue (it's p1 or p2sprpriority btw)

The anim is a looping one, which goes back ti the first frame, when it reached the last frame. It, however, misses many frames, since it's and Hi-Res effect. However, most effects have missing frames, and they work fine, so the missing frames are not the cause for this.
Now I need to know: Do I change the time in the ChangeState to 0 or do I change the value of something else to 0? I'm kind of confused a bit.

[Cyanide]

You change the line

anim = 4205
to
anim = 0

If there is a bad sprite in 4205, this will tell us. It is longer than 2 frames yeah? So the problem may be occuring in some of the animation that's happening in 4208? We don't know and can't tell. There is nothing wrong with the code that would cause a "no message" crash. We think it's sprites. To prove it's sprites we need to take the existing ones out of the equation.

[TrinitroRoy]

You change the line

anim = 4205
to
anim = 0

If there is a bad sprite in 4205, this will tell us. It is longer than 2 frames yeah? So the problem may be occuring in some of the animation that's happening in 4208? We don't know and can't tell. There is nothing wrong with the code that would cause a "no message" crash. We think it's sprites. To prove it's sprites we need to take the existing ones out of the equation.

Okay, I changed the current anim in state 4207 with an functional one, that normally does not crash MUGEN.
MUGEN still crashes with no message.

[Cyanide]

Comment out state 4208 altogether. Replace with the following

[Statedef 4208]
type = S
Movetype = I
physics = N
ctrl = 0
anim = 4205

[State Destroyself]
type = destroyself
trigger1 = animtime = 0

That's all i want there. If THAT crashes we have a problem with your changestate, or state -2. Although why state -2 would be causing the problem only in this siuation is a bit odd. There is an issue with your changestate in 4207, but that's just because it you never put the parent in anim 4204 so i don't see that doing more than making it trigger before you really want it to.

[TrinitroRoy]

Changed.
Oddly enough, the crash is not there anymore.
So the problem lies in State 4208?

[Cyanide]

Copy past sctrls over 1 by 1. Ie, copy paste>test>copy paste>test etc.

If it works after that, you have had the rare and severely annoying "bit of text is corrupt"

[TrinitroRoy]

Okay, I did your method.
MUGEN did not crash when adding back the code one by one...until I re-added this:

Code Select Expand


[State 4208]
type = AngleDraw
trigger1 = time > 0
scale = 2, fvar(10)
;value = 45
ignorehitpause = 1

Is there something wrong with that code?

Also, a new problem occured, though I will explain it later.

[Cyanide]

No there is not.

Delete that sctrl. And type it in again. Preferably not on the same lines you pasted it into, move it down a bit or something.

[TrinitroRoy]

Did it.
MUGEN still crashes with no message.

[Cyanide]

Seriously nothing wrong with it. The only things we can do to it now are swap the fvar for a normal number. No way in balls that fvar should be causing a crash. It's a helper, it's seperate from the rest of your characters code, it has no access to state -2. That fvar CAN'T be doing shit. other than scaling.

I am tempted to ask for the character at this point.

[TrinitroRoy]

Okay, I swapped the fvar for a normal number.
Now, MUGEN does NOT crash anymore. That's odd.

[Seravy]

Weird, you do have proper code to set the value of the variable so it should be working with it.

You haven't added it after the destroyself controller by chance? Code after the destroyself can cause crashes in Winmugen, especially if it does something like accessing variables.

[Ricepigeon]

Weird, you do have proper code to set the value of the variable so it should be working with it.

You haven't added it after the destroyself controller by chance? Code after the destroyself can cause crashes in Winmugen, especially if it does something like accessing variables.

He posted the code on the previous page, the destroyself comes last. Looking at the code it seems like a copypaste of my code, which I haven't had an error with. I cant go back to check which character specifically it was taken from, since all my Touhou stuff was deleted from my HDD, unless he took it from one of Kohaku's characters (which I did do some bugtesting for from time to time and fixed some of his code when needed, that and the master spark code uses the same exponential variation for hitsparks that Kohaku used, mine just used a simple additive random trigger to swap between hitspark variants.)

[TrinitroRoy]

Weird, you do have proper code to set the value of the variable so it should be working with it.

You haven't added it after the destroyself controller by chance? Code after the destroyself can cause crashes in Winmugen, especially if it does something like accessing variables.

He posted the code on the previous page, the destroyself comes last. Looking at the code it seems like a copypaste of my code, which I haven't had an error with. I cant go back to check which character specifically it was taken from, since all my Touhou stuff was deleted from my HDD, unless he took it from one of Kohaku's characters (which I did do some bugtesting for from time to time and fixed some of his code when needed, that and the master spark code uses the same exponential variation for hitsparks that Kohaku used, mine just used a simple additive random trigger to swap between hitspark variants.)

Yes, you're right. The code is based of Kohaku's char (Kohaku gets credited, together with you, who was actually the inspiration for doing Touhou chars in your style).
In fact, I only started to add other things, when I noticed, that my char became too much equal to Kohaku's original char.
So I went with adding 4 new hypers. Two of them were coded myself, one of them is based of one of your chars (it's Orreries Sun with some some original flair (coughmysticstarecough)), and the one listed there is a combination of:
- the two hypers, that I coded myself
and
- an alternation of Master Spark (which causes the crash there), that gets shot diagonally
However, if you know a better way of simulating the Master Spark shrink, I would be extremely glad.
By the way, I already edited most of the attacks, that Kohaku's original char had, so they would fit the system of your Touhou chars, like simplifying some hypers and adding Y and Z versions to the specials.

[Cyanide]

I wonder. Would an integer value on the X scale make mugen look for an integer on Y?

Change the 2 to 2.00.

This is called "Mugen is fucking stupid sometimes, lets do something fucking stupid"

There is honestly nothing wrong with what you have and i can't see why this would break.

[TrinitroRoy]

OK, tried it.
MUGEN still crashes...

[Cyanide]

Going to test it myself tonight then (or someone else can) That should be easily replicateable.

Still retarded though.