BND
Smash Apprentice
- Joined
- Jul 13, 2014
- Messages
- 174
NOTE: For those who don't know what the glitch is, if you plant a mine in the center of the stage and pull out a grenade, it inexplicably explodes. Furthermore, it doesn't matter if a Snake other than the one who planted the mine pulls out a grenade; the mine still explodes. This is a PM-specific glitch; it doesn't happen in Brawl.
Managed to find an actual bugfix as well as the root cause from 6-27-15 to 6-30-15 without resorting to modification of Snake's mine. Apparently the key components of the problem originated in Brawl: if you pull out a grenade, for less than a frame, it appears in the center of the stage. Brawl's mines did not detect airborne grenades, so it didn't happen in Brawl; however, in PM, airborne targets blew up the mine. Thus grenades, which appeared in the center for a little bit, did trigger the mine.
The fix was stumbled upon by accident, but basically the opcode 10090100: Value-13 (which drops a given article, with Value 13 being a grenade for Snake), if put in front of 100A0300: Value-13, Value-57, Value-2, which binds the grenade to Snake's hand, safely drops the grenade next to Snake, but he's left holding nothing. However, putting another 100A0300: Value-13, Value-57, Value-2, after this rebinds the grenade to Snake's hand, and everything goes as planned.
With that being said, the problem can be fixed by replacing 100A0300|0\13|0\57|0\2|/, or 100A0300: Value-13, Value-57, Value-2, with:
100A0300: Value-13, Value-57, Value-2,
10090100: Value-13,
100A0300: Value-13, Value-57, Value-2,
or just 100A0300|0\13|0\57|0\2|/10090100|0\13|/100A0300|0\13|0\57|0\2|/, in both SpecialNStart and SpecialAirNStart.
(Note that this fix relies on Snake having access to only one grenade. If there are two, then the other one falls down as well. This is the basis of grenade stripping)
~~~~
Managed to find an actual bugfix as well as the root cause from 6-27-15 to 6-30-15 without resorting to modification of Snake's mine. Apparently the key components of the problem originated in Brawl: if you pull out a grenade, for less than a frame, it appears in the center of the stage. Brawl's mines did not detect airborne grenades, so it didn't happen in Brawl; however, in PM, airborne targets blew up the mine. Thus grenades, which appeared in the center for a little bit, did trigger the mine.
The fix was stumbled upon by accident, but basically the opcode 10090100: Value-13 (which drops a given article, with Value 13 being a grenade for Snake), if put in front of 100A0300: Value-13, Value-57, Value-2, which binds the grenade to Snake's hand, safely drops the grenade next to Snake, but he's left holding nothing. However, putting another 100A0300: Value-13, Value-57, Value-2, after this rebinds the grenade to Snake's hand, and everything goes as planned.
With that being said, the problem can be fixed by replacing 100A0300|0\13|0\57|0\2|/, or 100A0300: Value-13, Value-57, Value-2, with:
100A0300: Value-13, Value-57, Value-2,
10090100: Value-13,
100A0300: Value-13, Value-57, Value-2,
or just 100A0300|0\13|0\57|0\2|/10090100|0\13|/100A0300|0\13|0\57|0\2|/, in both SpecialNStart and SpecialAirNStart.
(Note that this fix relies on Snake having access to only one grenade. If there are two, then the other one falls down as well. This is the basis of grenade stripping)
~~~~
PRELIMINARY NOTE: This may or may not interest you. Read on if you're curious and/or have something to add here, or just like reading through walls of text with no pictures.
PRELIMINARY NOTE 2: I've confirmed the cause of the actual explosion as of 6-30. Currently writing code to try to fix it.
~~~~
PRELIMINARY NOTE 2: I've confirmed the cause of the actual explosion as of 6-30. Currently writing code to try to fix it.
I've recently fallen into a lull of apathy and boredom, so in an attempt to jump start my senses and get a spark of sorts going, I've decided to forgo my responsibilities for a bit and do some investigation on the mine-grenade glitch. Not sure if I'm going to do more work on this in the morning, though I figured now would be a good time to unload my work; I'm slated to be busy in the next few days, and having an ISO compile time of 10 minutes is really inefficient.
For those who don't know what the glitch is, if you plant a mine in the center of the stage and pull out a grenade, it inexplicably explodes. Furthermore, it doesn't matter if a Snake other than the one who planted the mine pulls out a grenade; the mine still explodes. This is a PM-specific glitch; it doesn't happen in Brawl.
According to Arrow (I'm guessing the brawl thing refers to the nature of the actual problem, since it simply doesn't happen in Brawl),
Indeed, 90% of Snake mains probably don't care, but to prevent further jank, I figured it may be a good idea to get a conversation going on this and get to the bottom of the problem, hopefully helping out the PMDT a bit here with needed manpower. Obviously the majority of us don't have years of experience of working in Brawlbox (I only started using it seriously in the past few days), but the PMDT are people and so are we, so I'm fairly sure we can get some useful progress on this.
So far I've taken the following steps, according to a journal I've been keeping:
For those who don't know what the glitch is, if you plant a mine in the center of the stage and pull out a grenade, it inexplicably explodes. Furthermore, it doesn't matter if a Snake other than the one who planted the mine pulls out a grenade; the mine still explodes. This is a PM-specific glitch; it doesn't happen in Brawl.
According to Arrow (I'm guessing the brawl thing refers to the nature of the actual problem, since it simply doesn't happen in Brawl),
but with the programming capabilities and whatnot of the PMDT, who are accustomed to using Brawlbox and the like, I get the feeling that this isn't a problem of "oh no, we can't figure out what causes this", and more of a "there are bigger problems in PM; instead of sifting through pages of assembly, let's shove a few people to poke around at this for an hour or two and hope they find something, since Snake mains don't care".
Indeed, 90% of Snake mains probably don't care, but to prevent further jank, I figured it may be a good idea to get a conversation going on this and get to the bottom of the problem, hopefully helping out the PMDT a bit here with needed manpower. Obviously the majority of us don't have years of experience of working in Brawlbox (I only started using it seriously in the past few days), but the PMDT are people and so are we, so I'm fairly sure we can get some useful progress on this.
So far I've taken the following steps, according to a journal I've been keeping:
1. I replaced the PM Snake files with Brawl Snake files (extracted using Dolphin). It seemed that Brawl didn't have this problem.
2. I narrowed down the problem to FitSnake.pac; changing this file alone causes the glitch. This means that the problem's centralized somewhere here.
3. I tried replacing the mineplant (Something like AttackLW4) and neutral grenade pull animations; nothing happened. The implications here is that there were no actual immediate problems with the moves themselves.
4. Dug around and found that Action274 controlled the grenade output and realized some lines between the vBrawl and PM Snakes' .pac files did not match (Notably, the subroutines were off by 1). I figured that this was PMDT adding in some extra subroutine in the previous numbers, but without any way to view the subroutines (I didn't know about the FitSnake.pac file holding the info at the time), I copied over Brawl's Action274 anyways.
It turned out that this safely dropped Snake's grenade, but it was no longer in his hand and he walked around without a grenade in his hand. Bummer.
5. I narrowed down the problem to Concurrent Infinite Loop (Type 9) @SubRoutine26 in the SubRoutines list.
6. I figured that I'd compile a list of Snake's articles. There were two obvious methods: shoot them out of Snake's tranq dart, or pull them out in lieu of grenades. While trying to figure out the difference between Article 12 and 13 (I later realized that 12 didn't seem to matter), I ended up shooting a grenade out of Snake's tranq dart. Instead of flying straight or even flying straight at all, it spawned in the middle of the stage, stationary [!!]
(Note that immediately after I did I found them all here ( http://opensa.dantarion.com/wiki/Articles_(Brawl) ). Waste of time but at least everything was correct, and there was more insight into the problem.)
Conclusions made on Day 1 (6-27):
1. Something weird was happening between the mine and grenades on a more sinister level.
2. It's possible to fix this glitch without resorting to silly workarounds, as evidenced by Subroutine 25 not blowing up the grenade. How it should be done is unknown.
3. Trying to spawn a grenade defaulted to the center of the stage (I also found out that mines sort of followed the same pattern while spawning them through a grenade pull, though not quite. It's not relevant to the topic at hand, so I won't detail it), exactly at the region in which the mines would auto-blow up.
Hypothesis: It's possible that the mine was supposed to spawn in the center of the stage and was somehow vacuumed to Snake's hand. This seemed to be debunked by the fact that replacing the animation with Subroutine25 fixed everything barring Snake holding the grenade properly. It's also somewhat weakly debunked by the fact that throwing a smart bomb into the center of the stage and pulling out a grenade doesn't blow up the grenade. The reason this isn't strong evidence is that it's entirely possible that the grenade's hurtbox has already moved by the time hurtbox checks occur.
The hypothesis is also strongly supported by the fact that mines can actually detonate before they're armed (which takes 15 frames) by planting another one immediately (which takes 11 frames to set down the mine). Thus it's a direct result of the detection box trigger, not an innate interaction between mines and grenades.
2. I narrowed down the problem to FitSnake.pac; changing this file alone causes the glitch. This means that the problem's centralized somewhere here.
3. I tried replacing the mineplant (Something like AttackLW4) and neutral grenade pull animations; nothing happened. The implications here is that there were no actual immediate problems with the moves themselves.
4. Dug around and found that Action274 controlled the grenade output and realized some lines between the vBrawl and PM Snakes' .pac files did not match (Notably, the subroutines were off by 1). I figured that this was PMDT adding in some extra subroutine in the previous numbers, but without any way to view the subroutines (I didn't know about the FitSnake.pac file holding the info at the time), I copied over Brawl's Action274 anyways.
It turned out that this safely dropped Snake's grenade, but it was no longer in his hand and he walked around without a grenade in his hand. Bummer.
5. I narrowed down the problem to Concurrent Infinite Loop (Type 9) @SubRoutine26 in the SubRoutines list.
6. I figured that I'd compile a list of Snake's articles. There were two obvious methods: shoot them out of Snake's tranq dart, or pull them out in lieu of grenades. While trying to figure out the difference between Article 12 and 13 (I later realized that 12 didn't seem to matter), I ended up shooting a grenade out of Snake's tranq dart. Instead of flying straight or even flying straight at all, it spawned in the middle of the stage, stationary [!!]
(Note that immediately after I did I found them all here ( http://opensa.dantarion.com/wiki/Articles_(Brawl) ). Waste of time but at least everything was correct, and there was more insight into the problem.)
Conclusions made on Day 1 (6-27):
1. Something weird was happening between the mine and grenades on a more sinister level.
2. It's possible to fix this glitch without resorting to silly workarounds, as evidenced by Subroutine 25 not blowing up the grenade. How it should be done is unknown.
3. Trying to spawn a grenade defaulted to the center of the stage (I also found out that mines sort of followed the same pattern while spawning them through a grenade pull, though not quite. It's not relevant to the topic at hand, so I won't detail it), exactly at the region in which the mines would auto-blow up.
Hypothesis: It's possible that the mine was supposed to spawn in the center of the stage and was somehow vacuumed to Snake's hand. This seemed to be debunked by the fact that replacing the animation with Subroutine25 fixed everything barring Snake holding the grenade properly. It's also somewhat weakly debunked by the fact that throwing a smart bomb into the center of the stage and pulling out a grenade doesn't blow up the grenade. The reason this isn't strong evidence is that it's entirely possible that the grenade's hurtbox has already moved by the time hurtbox checks occur.
The hypothesis is also strongly supported by the fact that mines can actually detonate before they're armed (which takes 15 frames) by planting another one immediately (which takes 11 frames to set down the mine). Thus it's a direct result of the detection box trigger, not an innate interaction between mines and grenades.
1. Tried to put PM and Brawl Snake in the game together by replacing another character with vBrawl Snake. Things did not go well (it crashes)
2. I got sick of digging around the code since I didn't know how to get to the subroutines and Google said next to nothing, so I started investigating the differences between Snake's vBrawl and PM mines and grenades.
3. It seems that the main difference between grenades was that if there exists one on the field, you can't spawn another one in PM; in the original, you'd need to get to the grenade count limit (2). No immediately problems there.
4. The mine properties seemed to be fairly different (For example, an obvious example is a smaller character detection box, and it became somewhat obvious that Brawl's mines were somewhat lacking. Heck, you could even jump through a mine and you wouldn't get hit.
5. Dropping a grenade into the vBrawl mine (without a hitbox; achievable by shielding after a grenade over a mine below a platform) doesn't make it explode.
6. I found http://opensa.dantarion.com/wiki/Hitbox_Flags_(Brawl)#Bit_13-26_.28Hit_Bits.29 while digging around on the internet. Apparently if bit 16 and (maybe or?) 23 are switched off, it appears that Snake's grenade would not affect Snake's mine. Unfortunately, despite digging around the Snake code for a few hours, I couldn't find any mention of the hitboxes. The PMDT definitely changed something here and has access to the mine files, though; otherwise, jumping through Snake's mine wouldn't hurt.
7. I did some separate tests. Dropping a ROB Gyro without a hitbox (Achievable by pulling out a grenade with the Gyro in hand right above the mine) doesn't blow up vBrawl Snake's mine. Dropping a Mr. Saturn doesn't blow it up either until it starts walking all over it. In contrast, all explode immediately for PM Snake [!!]
8. I got access to the subroutines and investigated Subroutine 21, which was very similar in composition to Subroutine 26. Nothing notable happened; perhaps Terminate Concurrent Infinite Loop?: Value-9 results in a problem?
Conclusions made on Day 2 (6-28):
1. This didn't happen in Brawl probably because Brawl's mine was so bad and missed so many things that PM's mine would explode on, in particular ROB's gyros and Snake's grenade.
2. Later found that the Subroutines were stored in FitSnake.pac. Suspiscious subroutines include 4 and 26. Less suspiscious suspiscious subroutines include 17, 21, and 45 (Resembles mine plant though could very well be box removal). Suspiscious-for-different-reasons subroutines include 25, for obvious reasons.
Note that Subroutine 6 controlled tranq; seemed like I was right about the external hitbox in that earlier post.
3. Even in the subroutines, the mine seems like it's nowhere to be found for some reason.
Hypothesis: It's seems highly likely that the Day 1 hypothesis was correct; pulling out a mine probably creates a grenade hurtbox in the center of the stage for a frame. Counter-evidence remains the same as Day 1's debunking.
2. I got sick of digging around the code since I didn't know how to get to the subroutines and Google said next to nothing, so I started investigating the differences between Snake's vBrawl and PM mines and grenades.
3. It seems that the main difference between grenades was that if there exists one on the field, you can't spawn another one in PM; in the original, you'd need to get to the grenade count limit (2). No immediately problems there.
4. The mine properties seemed to be fairly different (For example, an obvious example is a smaller character detection box, and it became somewhat obvious that Brawl's mines were somewhat lacking. Heck, you could even jump through a mine and you wouldn't get hit.
5. Dropping a grenade into the vBrawl mine (without a hitbox; achievable by shielding after a grenade over a mine below a platform) doesn't make it explode.
6. I found http://opensa.dantarion.com/wiki/Hitbox_Flags_(Brawl)#Bit_13-26_.28Hit_Bits.29 while digging around on the internet. Apparently if bit 16 and (maybe or?) 23 are switched off, it appears that Snake's grenade would not affect Snake's mine. Unfortunately, despite digging around the Snake code for a few hours, I couldn't find any mention of the hitboxes. The PMDT definitely changed something here and has access to the mine files, though; otherwise, jumping through Snake's mine wouldn't hurt.
7. I did some separate tests. Dropping a ROB Gyro without a hitbox (Achievable by pulling out a grenade with the Gyro in hand right above the mine) doesn't blow up vBrawl Snake's mine. Dropping a Mr. Saturn doesn't blow it up either until it starts walking all over it. In contrast, all explode immediately for PM Snake [!!]
8. I got access to the subroutines and investigated Subroutine 21, which was very similar in composition to Subroutine 26. Nothing notable happened; perhaps Terminate Concurrent Infinite Loop?: Value-9 results in a problem?
Conclusions made on Day 2 (6-28):
1. This didn't happen in Brawl probably because Brawl's mine was so bad and missed so many things that PM's mine would explode on, in particular ROB's gyros and Snake's grenade.
2. Later found that the Subroutines were stored in FitSnake.pac. Suspiscious subroutines include 4 and 26. Less suspiscious suspiscious subroutines include 17, 21, and 45 (Resembles mine plant though could very well be box removal). Suspiscious-for-different-reasons subroutines include 25, for obvious reasons.
Note that Subroutine 6 controlled tranq; seemed like I was right about the external hitbox in that earlier post.
3. Even in the subroutines, the mine seems like it's nowhere to be found for some reason.
Hypothesis: It's seems highly likely that the Day 1 hypothesis was correct; pulling out a mine probably creates a grenade hurtbox in the center of the stage for a frame. Counter-evidence remains the same as Day 1's debunking.
1. I added the code of SubRoutine25 onto the back of SubRoutine26. Caused a semi-interesting effect: if you tap B, Snake can throw a grenade normally. If you hold B, the grenade drops onto the floor.
The interesting part here is that if you tap B, the mine blows up in the center of the stage if present as usual. However, if you hold B, it drops from Snake's hand and the mine in the center of the stage is safe.
There may be something interesting going on here.
2. I double checked the properties of Brawl's mine. It seems that it actually does detonate if Snake's grenade is next to it without a hitbox, but only if it's no longer bouncing. The same does not appear to apply for ROB's gyro. Not sure what's going on now.
3. I removed 0D010100|0\9|/, or "Terminate Concurrent Infinite Loop?: Value-9," from Subroutine25 + Subroutine 26. It seems that this is the line that lets Snake chain into Snake's grenade throwing animations, though I'm not sure about this yet.
4. I put the aforementioned line back and removed the 120A0100|5\570425360|/, or "Bit Variable Set: RA-Bit[16] = true", line instead. Nothing happened; I still don't know what that bit is for, though it's featured in Action274's "Additional Change Action Requirement Value Bit is Set: RA-Bit[16]". Will figure it out later.
5. I removed the dependency on SubRoutine26 in Action 274. In particular, I took out
02010200|0\301|6\1|/02040200|6\8|5\570425360|/02010200|0\290|6\1|/02040100|6\3|/02010200|0\299|6\1|/02040100|6\4|/0D000200|0\9|2\2,-1,26|/, or, in actual text:
Change Action action=301, requirement=Animation End
Additional Change Action Requirement Value Bit is Set: RA-Bit[16]
Change Action action=290, requirement=Animation End
Additional Change Action Requirement On Ground
Change Action action=299, requirement=Animation End
Additional Change Action Requirement In Air
Concurrent Infinite Loop (Type 9) @SubRoutine26 in the SubRoutines list
The removal of these lines gave the same results as just appending Subroutine 25 to 26.
6. I removed the contents of SubRoutine 26 entirely and couldn't tell the difference between that Snake build and normal PM Snake.
7. I put 10090100|0\13|/, or "10090100: Value-13", into Snake's SubRoutine26. Apparently this makes the grenade float weirdly around him. The Value-13 may be Snake's article number. If I didn't know any better, I'd think that this code means to drop all of Snake's grenades until he's done throwing, as this is exactly what happened (I stationed a character next to snake and picked up grenades for a while until Snake was done throwing)
8. Suspicions largely confirmed: I set Brawl Snake's Subroutine 26 as previously mentioned, and during both grenade pull and throw animations, the grenade kept falling out of another character's hand as they tried to pick it up repeatedly. Under normal circumstances, the grenade would stay in the character's hand.
9. It seems that my deduction was correct; I removed the relevant line in SubRoutine25, and shield grenade no longer drops a grenade. Getting hit out of the grenade animation also keeps the grenade as a prop in Snake's hand.
10. On a whim, set 10090100 for Value 0 (mine) under SubRoutine25. This results in the mine teleporting under Snake every time he pulls out a grenade and shields or gets hit. This would be great if it weren't for the fact that:
1. If Snake's in the air, the mine blows up if hit or it touches the ground. It's possible to have this statement activate only if Snake shields, but that makes the air case more gimmicky.
2. Teleporting the mine causes it to re-arm, extending its duration.
11. Removing SubRoutine 4's contents results in the grenade sticking to Snake's hand during the grenade lobs.
Conclusions made on Day 3 (6-29):
1. Subroutine 26 is actually innocent. It just so happens that Subroutine 25 forces a grenade drop [!!]
2. Subroutine 26 does, however, somehow chain into the standard grenade throw even when Subroutine 25 is placed before it. Suspecting that there's some race condition thing going on, though I don't have any leads.
The interesting part here is that if you tap B, the mine blows up in the center of the stage if present as usual. However, if you hold B, it drops from Snake's hand and the mine in the center of the stage is safe.
There may be something interesting going on here.
2. I double checked the properties of Brawl's mine. It seems that it actually does detonate if Snake's grenade is next to it without a hitbox, but only if it's no longer bouncing. The same does not appear to apply for ROB's gyro. Not sure what's going on now.
3. I removed 0D010100|0\9|/, or "Terminate Concurrent Infinite Loop?: Value-9," from Subroutine25 + Subroutine 26. It seems that this is the line that lets Snake chain into Snake's grenade throwing animations, though I'm not sure about this yet.
4. I put the aforementioned line back and removed the 120A0100|5\570425360|/, or "Bit Variable Set: RA-Bit[16] = true", line instead. Nothing happened; I still don't know what that bit is for, though it's featured in Action274's "Additional Change Action Requirement Value Bit is Set: RA-Bit[16]". Will figure it out later.
5. I removed the dependency on SubRoutine26 in Action 274. In particular, I took out
02010200|0\301|6\1|/02040200|6\8|5\570425360|/02010200|0\290|6\1|/02040100|6\3|/02010200|0\299|6\1|/02040100|6\4|/0D000200|0\9|2\2,-1,26|/, or, in actual text:
Change Action action=301, requirement=Animation End
Additional Change Action Requirement Value Bit is Set: RA-Bit[16]
Change Action action=290, requirement=Animation End
Additional Change Action Requirement On Ground
Change Action action=299, requirement=Animation End
Additional Change Action Requirement In Air
Concurrent Infinite Loop (Type 9) @SubRoutine26 in the SubRoutines list
The removal of these lines gave the same results as just appending Subroutine 25 to 26.
6. I removed the contents of SubRoutine 26 entirely and couldn't tell the difference between that Snake build and normal PM Snake.
7. I put 10090100|0\13|/, or "10090100: Value-13", into Snake's SubRoutine26. Apparently this makes the grenade float weirdly around him. The Value-13 may be Snake's article number. If I didn't know any better, I'd think that this code means to drop all of Snake's grenades until he's done throwing, as this is exactly what happened (I stationed a character next to snake and picked up grenades for a while until Snake was done throwing)
8. Suspicions largely confirmed: I set Brawl Snake's Subroutine 26 as previously mentioned, and during both grenade pull and throw animations, the grenade kept falling out of another character's hand as they tried to pick it up repeatedly. Under normal circumstances, the grenade would stay in the character's hand.
9. It seems that my deduction was correct; I removed the relevant line in SubRoutine25, and shield grenade no longer drops a grenade. Getting hit out of the grenade animation also keeps the grenade as a prop in Snake's hand.
10. On a whim, set 10090100 for Value 0 (mine) under SubRoutine25. This results in the mine teleporting under Snake every time he pulls out a grenade and shields or gets hit. This would be great if it weren't for the fact that:
1. If Snake's in the air, the mine blows up if hit or it touches the ground. It's possible to have this statement activate only if Snake shields, but that makes the air case more gimmicky.
2. Teleporting the mine causes it to re-arm, extending its duration.
11. Removing SubRoutine 4's contents results in the grenade sticking to Snake's hand during the grenade lobs.
Conclusions made on Day 3 (6-29):
1. Subroutine 26 is actually innocent. It just so happens that Subroutine 25 forces a grenade drop [!!]
2. Subroutine 26 does, however, somehow chain into the standard grenade throw even when Subroutine 25 is placed before it. Suspecting that there's some race condition thing going on, though I don't have any leads.
1. I added in the line 10090100 Value 13 before and after (two tests, not together) SpecialNStart's 100A0300, the latter of which binds the grenade to Snake's hand. Putting it before the code does absolutely nothing and is identical to normal PM Snake, but putting it immediately after the code unbinds the grenade from Snake's hand, and does not cause mines in the middle of the stage to explode. In other words, if the grenade is in Snake's hand, it causes an explosion.
2. YA SNEAKY LITTLE GRENADE I SEE YOU (http://puu.sh/iIFNT/56f364877a.jpg)
This setup was achieved by binding the grenade to Snake's hand one frame later than normal.
3. I tried to force the game to pull out the grenade and bind it in Snake's hand, all within frame 8 and hopefully before detection boxes were set. No suck luck.
4. Found the opcode 1F080100, which let you generate an item in your hand. Unfortunately, this item counts as a generic item, not a character specific item. (It also still makes the mine in the center of the stage blow up)
5. Went back to the original generate grenade code, and did a bit of thinking. First I generated Article 13, then attached it to Snake's hand. Then I applied the drop grenade code, since that apparently fixed things. The frame immediately afterwards, I forced the grenade back into Snake's hand. Bugfix get!
2. YA SNEAKY LITTLE GRENADE I SEE YOU (http://puu.sh/iIFNT/56f364877a.jpg)
This setup was achieved by binding the grenade to Snake's hand one frame later than normal.
3. I tried to force the game to pull out the grenade and bind it in Snake's hand, all within frame 8 and hopefully before detection boxes were set. No suck luck.
4. Found the opcode 1F080100, which let you generate an item in your hand. Unfortunately, this item counts as a generic item, not a character specific item. (It also still makes the mine in the center of the stage blow up)
5. Went back to the original generate grenade code, and did a bit of thinking. First I generated Article 13, then attached it to Snake's hand. Then I applied the drop grenade code, since that apparently fixed things. The frame immediately afterwards, I forced the grenade back into Snake's hand. Bugfix get!
If you want to contribute, it's fairly simple to get things working. To give a quick guide as to how you can get all of the info you need:
1. Download a recent version of brawlbox, and open two Brawlbox windows.
2. On one of them, open up FitSnake0X.pac, go to ModelData[0] and 3DModels(NW4R), click the FitSnake03 model, and press ctrl+P (or edit -> preview).
3. Open up all of the sidebars, and on the top menu bar go to moveset -> load -> FitSnake.pac. If you can't visualize Snake's moveset or otherwise have trouble visualizing them, I advise you go to File -> Animations -> Load -> FitSnakeMotionEtc.pac (or just ctrl+O) as well.
All of this should give you access to the actions and subactions.
4. On your second Brawlbox window, open up FitSnake.pac. One of the subfolders should have all subroutines in them; there may be more info elsewhere.
5. Optional, but opening up common3.pac may have some info. Seems like it's not entirely relevant though.
1. Download a recent version of brawlbox, and open two Brawlbox windows.
2. On one of them, open up FitSnake0X.pac, go to ModelData[0] and 3DModels(NW4R), click the FitSnake03 model, and press ctrl+P (or edit -> preview).
3. Open up all of the sidebars, and on the top menu bar go to moveset -> load -> FitSnake.pac. If you can't visualize Snake's moveset or otherwise have trouble visualizing them, I advise you go to File -> Animations -> Load -> FitSnakeMotionEtc.pac (or just ctrl+O) as well.
All of this should give you access to the actions and subactions.
4. On your second Brawlbox window, open up FitSnake.pac. One of the subfolders should have all subroutines in them; there may be more info elsewhere.
5. Optional, but opening up common3.pac may have some info. Seems like it's not entirely relevant though.
1. The appearance of a grenade has nothing to do with the mine exploding. The two items are not related.
2. Snake taking the holding-a-grenade stance also has nothing to do with the mine exploding.
3. The problem is centralized in FitSnake.pac.
4. Snake's grenades, by default, spawn where the mine blows up. This may apply to other items as well, though I don't quite feel like testing it. (Next on the list is to replace Link's boomerang with a bomb and see if it forces the bomb to spawn in the center of the stage and/or to replace ROB's laser with his gyro.)
5. Pulling out a grenade does not trigger the mine until it is armed.
6. Grenades, even without a hitbox, make mines explode. This does not appear to be the case in Brawl, where the glitch doesn't technically happen. (It's possible that the mine only hits completely grounded objects and not bouncing ones, as Brawl mines don't hit airborne targets.)
7. The code 10090100 Value X seems to teleport all article X's in some less-than-obvious fashion. In particular, said article X's are dropped.
8. The mine explosion is indeed caused by the grenade spawning in the center of the stage.
2. Snake taking the holding-a-grenade stance also has nothing to do with the mine exploding.
3. The problem is centralized in FitSnake.pac.
4. Snake's grenades, by default, spawn where the mine blows up. This may apply to other items as well, though I don't quite feel like testing it. (Next on the list is to replace Link's boomerang with a bomb and see if it forces the bomb to spawn in the center of the stage and/or to replace ROB's laser with his gyro.)
5. Pulling out a grenade does not trigger the mine until it is armed.
6. Grenades, even without a hitbox, make mines explode. This does not appear to be the case in Brawl, where the glitch doesn't technically happen. (It's possible that the mine only hits completely grounded objects and not bouncing ones, as Brawl mines don't hit airborne targets.)
7. The code 10090100 Value X seems to teleport all article X's in some less-than-obvious fashion. In particular, said article X's are dropped.
8. The mine explosion is indeed caused by the grenade spawning in the center of the stage.
1. Somehow pause the mine character detection box on the frame a grenade spawns in a similar manner as read and write locks.
2. Remove the grenade detection bits on mines, assuming that it exists.
2. Remove the grenade detection bits on mines, assuming that it exists.
1. Get vBrawl and PMSnake together in the same game. Have each plant a mine in the center of the stage, and have each pull out a grenade for the other. If vBrawl's grenade activates PMSnake's mine, it's the mine's fault, and we can largely confirm the hypothesis. Otherwise, more work may be needed.
2. Check the hit bits on PMSnake's mine.
3. Figure out how to utilize SubRoutine25 to rewrite Subroutine26.
4. See if other things spawn in the center of the stage by default; if they do, then we may have a problem. If not, try to rewrite the code to match their's.
5. Double check that no combination was overlooked regarding Frankensteining PM and vBrawl Snake; in particular, confirm that the mine detection box is controlled by FitSnake.pac.
2. Check the hit bits on PMSnake's mine.
3. Figure out how to utilize SubRoutine25 to rewrite Subroutine26.
4. See if other things spawn in the center of the stage by default; if they do, then we may have a problem. If not, try to rewrite the code to match their's.
5. Double check that no combination was overlooked regarding Frankensteining PM and vBrawl Snake; in particular, confirm that the mine detection box is controlled by FitSnake.pac.
Last edited:
