Is there a 3rd Strike ROM from 30th Anniversary around? (Fatal bug fixed)

[Darksoft]

You'd still be reading trace logs of sh2 asm to find the bug.

did you ever tried it at practice ? with CPS3 games
@Hatsune Mike I've already solved it, as was said - it is 1byte fix in game data.
however in 30th anniversary emulator it was fixed not by patching data but using "code execution hook", which is doing the same thing. not sure why they did it in a bit more hard way.

@MetalliC Great job! Can you share that byte data and I'll update a new ISO, so people can decide if they want to play the original or the FIXED version?

 

[KaPH33n]

@MetalliC Great job! Can you share that byte data and I'll update a new ISO, so people can decide if they want to play the original or the FIXED version?

I vote that we call it ver. C (for Community), as it's the product of over 20 years of play and a dedicated community. and that we hack the startup message with a new date code... I think even if it is fully supported by the tournament circuits, or not, it will be good to have an easily distinguishable version for it. I wouldn't want someone to be misled accidentally or not.

 

[Wraith]

I’ve been in the 3s scene a little over a year now, I remember it happening once at TFC 2018 where tony majors had to walk over and reset the cab.

It’s not common but if we can be 100% sure that nothing else is altered with this bug fix, and darksoft and mitsurugi are behind it, I guarantee the 3s scene will fully embrace it

 

[plasia]

I’ve been in the 3s scene a little over a year now, I remember it happening once at TFC 2018 where tony majors had to walk over and reset the cab.

It’s not common but if we can be 100% sure that nothing else is altered with this bug fix, and darksoft and mitsurugi are behind it, I guarantee the 3s scene will fully embrace it

That's what we've got to test.

I also like that "ver C" idea, or at least telling people it's the makoto fixed version somehow.

When everything is confirmed to not effect anything else I will give some appreciation money to metallic and darksoft.

 

[Darksoft]

Makes sense to us. As soon as we get the fix, we'll prepare a release.

 

[Niko]

When this is released, I think it would also be a good idea to share exactly which byte was changed and why it fixes the issue.

This will help focus the testing to a specific area, and aid in having it accepted by the community.

 

[MetalliC]

When this is released, I think it would also be a good idea to share exactly which byte was changed and why it fixes the issue.

when running sfiii3nr1 set in MAME enter in debugger: "wps 638fc62,2,r", original value stored at this address is 0x000A. much later it leads to JSR to bad address in this code

ROM:06125DF8                 mov     #h'28, r0
ROM:06125DFA                 mov.w   @(r0,r14), r3 ; 0 leads to crash
ROM:06125DFC                 mov.l   #off_65EC870, r0
ROM:06125DFE                 add     #-h'C, r3
ROM:06125E00                 shll2   r3
ROM:06125E02                 mov.l   @(r0,r3), r2
ROM:06125E04                 jsr     @r2
ROM:06125E06                 mov     r14, r4

quite ironically, Capcom fixed issue by that value change from 0x000A to 0x000B
good luck in tracing tons of code trying to find how one leads to another, and how A->B fixes it, I'm not interested to do this.

This will help focus the testing to a specific area, and aid in having it accepted by the community.

honestly ? it looks like all this SF3 scene/community consists only from "bla-bla-bla" type of people, who only capable of typing 7 pages of this topic, and doing nothing useful.
also they have zero tech skills, so I no idea based on what they may decide is it acceptable, and in general I'm not any cared if it will be accepted or not by sf3 1337 $c3n3.

 

[Wraith]

When this is released, I think it would also be a good idea to share exactly which byte was changed and why it fixes the issue.

when running sfiii3nr1 set in MAME enter in debugger: "wps 638fc62,2,r", original value stored at this address is 0x000A. much later it leads to JSR to bad address in this code

ROM:06125DF8                 mov     #h'28, r0
ROM:06125DFA                 mov.w   @(r0,r14), r3 ; 0 leads to crash
ROM:06125DFC                 mov.l   #off_65EC870, r0
ROM:06125DFE                 add     #-h'C, r3
ROM:06125E00                 shll2   r3
ROM:06125E02                 mov.l   @(r0,r3), r2
ROM:06125E04                 jsr     @r2
ROM:06125E06                 mov     r14, r4

quite ironically, Capcom fixed issue by that value change from 0x000A to 0x000B
good luck in tracing tons of code trying to find how one leads to another, and how A->B fixes it, I'm not interested to do this.

This will help focus the testing to a specific area, and aid in having it accepted by the community.

honestly ? it looks like all this SF3 scene/community consists only from "bla-bla-bla" type of people, who only capable of typing 7 pages of this topic, and doing nothing useful.also they have zero tech skills, so I no idea based on what they may decide is it acceptable, and in general I'm not any cared if it will be accepted or not by sf3 1337 $c3n3.

LMAO

 

[Arlieth]

When this is released, I think it would also be a good idea to share exactly which byte was changed and why it fixes the issue.

when running sfiii3nr1 set in MAME enter in debugger: "wps 638fc62,2,r", original value stored at this address is 0x000A. much later it leads to JSR to bad address in this code

ROM:06125DF8                 mov     #h'28, r0
ROM:06125DFA                 mov.w   @(r0,r14), r3 ; 0 leads to crash
ROM:06125DFC                 mov.l   #off_65EC870, r0
ROM:06125DFE                 add     #-h'C, r3
ROM:06125E00                 shll2   r3
ROM:06125E02                 mov.l   @(r0,r3), r2
ROM:06125E04                 jsr     @r2
ROM:06125E06                 mov     r14, r4

quite ironically, Capcom fixed issue by that value change from 0x000A to 0x000B
good luck in tracing tons of code trying to find how one leads to another, and how A->B fixes it, I'm not interested to do this.

This will help focus the testing to a specific area, and aid in having it accepted by the community.

honestly ? it looks like all this SF3 scene/community consists only from "bla-bla-bla" type of people, who only capable of typing 7 pages of this topic, and doing nothing useful.also they have zero tech skills, so I no idea based on what they may decide is it acceptable, and in general I'm not any cared if it will be accepted or not by sf3 1337 $c3n3.

Bruh I'm just glad you did the work for this. Thank you very much. I was just annoyed at the "NO IF PEOPLE WANT THIS FIXED THEY MUST RUN REV. B" whining.

Also lol at the A>B thing.

The tournament stuff is just pretty much "yes this will be put to good use". 4th Strike was an interesting thing to play with but this is something that will hopefully stick around for much longer.

 

[SabreAZ]

I still dont see the 3s scene signing off on this. As noble as the attempt is, cuz now we are modifying game code, so I could see people being apprehensive with this

Just takes Mutant signing off on it as Jazzy certified and there's nothing to really worry about in the US. Get Art on board and run it at NLBC and there's another easy win. I'll hopefully see him this week, I'll ask him what he thinks.
I can think of some people who won't want to run it, but I don't really care what they think about anything anymore, so welp lol. Not like anyone has to.

no doubt. I'm personally not against it by any means, I'm all for it. And props to @MetalliC for figuring it out.

I almost wonder if even telling the majority scene is worth it, and just let the TOs know, and the fickle players wont even notice lol

 

[KaPH33n]

I'm of the opinion that no information should be misleading or unclear when we have the ability to be concrete. I personally believe that every tournament should list exactly the hardware that they are playing the tournament on to the best of their ability. It should be stated if it's on supergun, a specific candy cab, US style with Happ sticks, or whatever. It should be stated if its ver. a or b (or c). I think it should even be obviously stated if the event is run on a battery cart, superbios, or reencrypted code for another game.

Similarly for CPS2 I think it should be stated if it's on a Multi. There's not any difference at all, but I just think tournaments should be fair and the conditions disclosed.

 

[Arlieth]

I'm of the opinion that no information should be misleading or unclear when we have the ability to be concrete. I personally believe that every tournament should list exactly the hardware that they are playing the tournament on to the best of their ability. It should be stated if it's on supergun, a specific candy cab, US style with Happ sticks, or whatever. It should be stated if its ver. a or b (or c). I think it should even be obviously stated if the event is run on a battery cart, superbios, or reencrypted code for another game.

Similarly for CPS2 I think it should be stated if it's on a Multi. There's not any difference at all, but I just think tournaments should be fair and the conditions disclosed.

This is fair in the US.

In Japan they cannot due this for legal reasons. A ton of arcades run Darksoft carts but they could get in huge trouble if they get caught.

 

[Darksoft]

I got the info already. I'll try to release the new ISO tomorrow and tidy up a bit the download section.

 

[GeeDee]

This is fair in the US.
In Japan they cannot due this for legal reasons. A ton of arcades run Darksoft carts but they could get in huge trouble if they get caught.

Out of curiosity, what do you think the community consensus would be overseas about using Ver.C? If someone were to cause the glitch, but the game didn't freeze...would there be some kind of discrepancy/controversy? Or would keeping it hush-hush fall under the "nail that sticks out gets hammered in" mentality?

 

[Aurich]

This is fair in the US.
In Japan they cannot due this for legal reasons. A ton of arcades run Darksoft carts but they could get in huge trouble if they get caught.

Out of curiosity, what do you think the community consensus would be overseas about using Ver.C? If someone were to cause the glitch, but the game didn't freeze...would there be some kind of discrepancy/controversy? Or would keeping it hush-hush fall under the "nail that sticks out gets hammered in" mentality?

Arli told me this isn't an issue because the glitch isn't consistent. Possible it doesn't happen. So there's no immediate 'tell' anyways.

 

[Darksoft]

I was talking to @TMF68k. He said that
* Fighting gamers won't play if the version is different from the version they were practicing.
* In Japan, the initial version, including the defect, was preferred.This is because the balance of the system varies from version to version.


So I understand that If we change the date or add anything that would make it visible for the users that it's different, they won't play it, at least in Japan. If it's a version that "justs" fixes the makoto fix with only that byte change, it will be accepted.
What it's not clear to me is if it will be accepted because they won't notice the change or if they will play it even knowing that the bug was fixed.

What about the rest of the world? What is the rule on this and what would be accepted by gamers?

 

[plasia]

The way I see it:

- People want to play version A.
- The bad thing about version A is the fatal bug.
- This new fixed rom is version A without the fatal bug.

therefore

- It is not different from what gamers practiced at home
- It is still the initial version people want to play

99.9% of gamers should be happy the bug is finally fixed, the 0.1% unhappy will be really loud about it, but don't turn up to events anyway. (I know this because I was a 3s TO for many years).

--- --- --- ---

It should be tested before it is given the "tournament OK" clearance, but I highly doubt it will effect anything except the bug. I am very thankful to Metallic for the fix and Darksoft for making it easy to do on real hardware.

 

[Arlieth]

The way I see it:

- People want to play version A.
- The bad thing about version A is the fatal bug.
- This new fixed rom is version A without the fatal bug.

therefore

- It is not different from what gamers practiced at home
- It is still the initial version people want to play

99.9% of gamers should be happy the bug is finally fixed, the 0.1% unhappy will be really loud about it, but don't turn up to events anyway. (I know this because I was a 3s TO for many years).

--- --- --- ---

It should be tested before it is given the "tournament OK" clearance, but I highly doubt it will effect anything except the bug. I am very thankful to Metallic for the fix and Darksoft for making it easy to do on real hardware.

Cosign on Plasia's breakdown.

It is a liability (in Japan) to visibly show that it is a different version than the others, for legal purposes. It would have to be the responsibility of arcade operators to observe if any unintended behavior occurs as a result of the patch for casual play; by making it explicitly known that this is a patched version you risk a placebo effect of someone complaining that a material gameplay change was effected.

Also, this is simply a 1-byte patch that was implemented by Capcom already in Rev B, as well as in run-time by Digital Ocean, so I don't see any unintended effects from it.

Rest of the world will be happy the bug is fixed, no matter what.

 

[Darksoft]

So....releasing new ISOs that will have only that bug fixed (1 byte) and no change in the date shown on screen or anything else, would be OK for the community?
Everyone agrees?

 

[ChuChu Flamingo]

then all we would be missing is a replacement for ver.B on the darksoft boot with a Ver.A that has infinite health and meter

It would be awesome to have a training mode for Third Strike that has infinite health and meter. Jojo's Bizarre Adventure as well.