You want to talk about non-standard controllers? Sticks are considered non-standard controllers since they are not the default controller for the console. If your argument is going to be about only the standard controller, then we’re only talking about the pad. And on the pad, SOCD’s are possible. OH HEY LOOK, IT’S STILL AN ISSUE!
And I see you’re already trying to call using a pad for it impractical. I posted in this thread how to hold the controller in such a way that not only are SOCD’s extremely practical, but you don’t have to let go of any other buttons to do them, and it’s been an accepted way to hold the pad for fighting games for years.
Fact of the matter is SFIV did not allow such inputs as well as a lot of other lesser known fighting games like Arcana Heart 3, so for a major title to not have a similar fix IS lazy, especially considering the fix to stop SOCD’s is about 5 lines of code that would have taken less than a minute to put in the game (thanks to Mike Z for that info). I also highly doubt putting in code that stops the game from registering someone pushing opposite directions at the same time would cause anything else to break.
If Capcom DOESN’T fix this issue, I will be severely surprised, seeing as how they are all about the competitive community when it comes to their fighting games, and with this bug everyone who isn’t playing on a stick would be banned from competing. I’m fairly certain that is something they would like to avoid.
Yeah, as a developer, you’re supposed to consider the protocol, not just intended uses of the protocol. And beyond that, you’re supposed to be able to fail gracefully when that protocol is breached.
Does the protocol allow for the game to receive SOCDs? Obviously, yes, it does. If so, it’s an issue with your software, not a non-standard hardware issue. Did Capcom know about SOCDs? Since HDR had the SOCD bug, yes.
Now, whether these games were coded in a way that makes this easy to fix is questionable, but I can’t imagine a situation where I would code this up and it would be difficult to change my program to yield neutral on the axis for an SOCD.
I think his point is that Capcom wouldn’t do a patch just for this issue by itself, even if it’s just a few lines of code.
If you change any little thing, you have to run through a test cycle and submit for a patch certification from first party (costs money for the submission and running everything through it’s normal paces).
Maybe they will sneak it in in one of the DLC prep updates later on or if they do a straight up patch (for online lag hopefully, hehe).
I understand that, but like you said, there’s several other things that could use some patching just in how the game runs itself, so I honestly believe that with the few updates this game gets it would be unacceptable to not fix SOCD’s.
Utter nonsense. Regression testing alone would likely run into dozens of man hours. You would not believe how much stuff like this costs to fix after everything is done and dusted (development, testing, certification etc.)
So I’m curious…why is it only TE-based hitboxes that are affected by this? What is different with Cthulhus, PS360s, and the like? Or have I just misread things severely in the thread?
@roxtc
Technically a d-pad is already a series of four buttons made to look different from the face buttons so you know which ones are the “directions”.
@drunkninja42
Granted, the PS360 and the MCCthulu do actually cause the SOCD problems on 360, they just don’t on the PS3, but you can use other PCB’s (pad, maybe TE) to do it on the PS3.
I’m thinking of asking Toodles to come in on this project, he has more expertise on this subject than I do (I feel ashamed at being a first-year EE student and not knowing a damn thing about this).
Guys, does anyone of you think that, maybe, the CAPCOM developers used this response (neutral on double inputs) for building all the work on it? So, if they change the foundations, they will have to rewrite half of what’s written on it?
Just asking…
As for the toodles thing, I have no background in electrical engineering, but would like to use a xor gate to remove the socd from hitbox. If he could write a quick guide on how to do that, It’d save me several hours of failing till I figure it out.
Also, I’m thinking a “socd pad shenanigans” video might be fun to make (and helpful in the whole “alerting TO’s this is not just a hitbox issue”.
Besides Crossup blocking and infinite gamma wave buffering with hulk (or is there a better charge move to do that with), what else would be good to include?
XOR gate wouldn’t do it. My nakpin scrawl Kmap for say ‘right’ direction is like this:
(Main is the direction for that set, and opposite is the opposite of it. For the gates responsible for the Right direction, ‘main’ is the signal for the Right pushbutton, and ‘opposite’ is the signal for the Left pushbutton. )
main\opposite 01
0 10
1 11
In boolean algebra, that reduces to "Direction= ((NOT opposite) OR main)"
So one OR gate and one inverter chip would handle all four directions. Pretty easy to throw together from that. Let me know if you need a schematic or board layout.
Not for the lazy-ass Capcom developers. Hell, they’re so incompetent according to you they probably wouldn’t even know how to.
Anyway, weren’t you demanding Capcom’s sloppy developers fix this before anyone found out the standard pad has the same issue and it was just your own product that was at stake?
@samaytg1
While that’s all well and good idea, the fact that SOCD’s aren’t “just a hit box issue” means that designing this NOR (…I really thought XOR would have been it…oh well) gate board to “eliminate” SOCD behavior may be putting the cart before the horse.
You would then kinda be implying that TO’s need to police fight boards, to make sure that they have these NOR “helper boards” or otherwise exhibit this wanted behavior. Which leads down the slippery slope situation I’ve already described which could possibly very unreasonably delay tournaments. I should mention I used to be a TO for Quake, and that kind of situation scares the shit out of me.
@Toodles,
Well, I’m trying to find a reasonable explanation on why SOCD behavior is much rarer on PS3 fight boards as opposed to 360 ones. One of my first assumptions was that most fight boards would have been built using either your MCC, or the PS360, which are known not to properly send SOCD signals. Others suggest the PS3 drivers/firmware/whatever in the console itself may be preventing SOCD behavior. I’m just trying to find an acceptable solution as to why SOCD’s are so rare on PS3 fight boards.
It’s a protocol issue. Most PS3 boards including my stuff, DualStrike, and boards from PS3 arcade sticks send the data in ways that mean they can’t send conflicting directions at the same time. Its part of the protocol vs hardware vs software I was talking about in that thread, and most boards use a protocol that can’t conflicting directions. If you want to verify whether or not the left+right block bug is in the PS3 version of mvc3, the easiest way I can think of would be to test using an AXISdapter. The SIXAXIS protocol (at least over USB) sends the dpad as separate bits, so should be able send left+right at the same time if I’m remembering correctly.
So someone who wanted to use a “cheating” fight board at EVO would simply have to build one via actual padhacking.
This, again, makes doing the whole thing of possibly policing use of “good” and “bad” fight boards completely unreasonable to TO’s.
I still can’t come up with any solution that’s reasonable other than to ban fight boards (which, again, won’t completely solve the problem of SOCD’s in any complete fashion anyway) from games that exist unfair behavior with SOCD’s, and pressuring the developers to patch this behavior.