Let's imagine we have 10 different wheels, all with different button configurations. You can obviously program each one individually, but it would be too much time, for too little outcome (in other words, if you invest the same time on something else you'll get more benefits). You'll probably have a standardized code that tries to cover all bases, instead.
I am going to stop you right there and explain that this assumption is already flawed. Programming support for a bunch of peripherals is not really hard at all... look at the PC world where the variety is much greater, the standards are much more open and yet games support MANY input devices... there is a reason for this and that is: It's not actually that hard to do, especially on a closed system like a PS3.
I will explain below, but suffice it to say, this assumption is already flawed and as such so is the rest of where you went... this is a classic case of knowing just enough to get into trouble.
As to you flaming my idea that the wheel manufacturers are themselves equally to blame, take a moment and ask yourself how many times this has happened to games in the past..? If this were the first, sure, blindsided. But game developers changing their input codes is by no means an unusual occurrence.
This makes no sense... every platform (be it OS or console) has a standard and adhears to it... gamers don't "change their input codes" gamers accept input codes from devices and map them... what you are saying makes no sense and is about the equivalent of saying "the telephone company routinely changes what numbers are acceptable on a phone and so phone makers should make their phones repgrammable to accept sending roman letters, hebrew alphabets or base 16 numbers". No they don't and no they shouldn't.
BTW it's been answered already how often this has happened in the past... on the PS3 alone I can't think of anytimes... every driving game I have played (including ones that predate the G27) work fine.
When standardized hardware is not supported, it's the game devs fault, plain and simple. See below for the reason behind that.
Why don't the peripheral manufacturers acknowledge this universal practice, and include some way to upgrade the firmware. In fact, some wheels DO allow this (Fanatic, for example). Why not direct your ire at Logitech? Oh, that's right. There HAS to be a conspiracy (or the entire thread would be a joke)
No, because your lack of undertanding of what you are talking about is causing you to not realize how unrealistic the idea you put forth is.
Why does someone who has firmly made up his mind on an issue even ASK for a reasoned discussion? You are just looking for a forum to whine. And, trust me, if this issue NEVER gets patched, I WILL mea culpa. Somehow, I doubt you will. You will just say it is PD bowing to the pressure you put on them to reverse their conspiracy... You want to see Reds under the bed, you WILL see reds under the bed
I am happy to recieve educated contradictory points of view, however your's was not that. If someone can provide actual examples and illustrate an understanding of what they are talking about that makes sense, I am more than happy to consider it. But if your examples show you have no understanding of the process at hand and make no sense, then on, I won't be accepting them.
Now I had wanted to avoid this arduous (and dangerous) method of really explaining it all in detail as it's akin to explaining brain surgery in a few pages... I can't simplify it enough and explain it enough in a reasonable length to not leave a bunch of potential holes in the analogy, but here is my best effort... VERY long read BTW:
So the communications pathway for an OS based system is going to be something like this generalized example:
Hardware identifies itself and it's functions to OS - OS standardizes hardware and it's functions and makes these avialble to software running on the OS - Software polls OS and communicates through the OS translation to the hardware.
So for example let's take a controller with 2 buttons and a gas pedal. For the sake of the example let's call the buttons Left and Right.
When you plug the controller in it will identify itself to the OS and if it's compatible with the OS's abilities, the OS will map the controller functions to standardized functions the software running on the OS can access.
So let's say on the controller there is Button1, Button2 and Axis1 referring to each of the two buttons and the analog gas pedal.
The OS intializes the hardware, recognizes it and it's inputs and maps these inputs to an OS standardized names Input1, Input2 and AxisX*. So now all buttons are available to software running on the system.
So you make your game and the game has 3 main variables, turn right, turn left and accelerate. Your pripheral map says TurnRight=Input1, TurnLeft=Input2, Gas=AxisX. Now when you press Butotn1, it tells the OS which translates this to Input1 and tells the game "Input1 was pressed".
So in your game under your peripheral maps you assign a section to this logitech wheel. In it you say "Input1 controls function TurnLeft" "Input2 controls function TurnRight" AxisX controls function Gas.
Now when you press a Button1, it tells the OS, the OS translates "Button1" into the standard "Inpout1" and passes on the message Input1 pressed, the game reads Input1 presssed and does function "TurnLeft". Note that the entire workings of "turning left" is done inside function TurnLeft. You do not recode a new TurnLeft for each wheel, you simply map the button on the wheel to function TurnLeft and when you make changes to fucntion TurnLeft (lets say you make it turn shaper) these changes do not trigger back any changes to your button mappings.
If you want to allow for user configuration, you set it up so when the user maps the button they can say now "Input1 controls function TurnRight" Input2 controls function TurnLeft".
The buttons are now effectively reversed.
This is very simplifide but you can see that it's not at all hard to do and can easily be done for a large number of devices without much trouble. There is no calculation being done at this stage, the physics and graphics engines all run in their own little areas and only recieve the message to do a funciton when a button gets pressed and you input module passes the message along to the appropriate function to do it's thing.
Now when Logitech is making this wheel, before they stamp "Compatible with PS3" on it, they check what the PS3 OS supports, since there isn't really such a thing as a driver as we think of on PCs which get installed with each piece of hardware, the PS3 has a standard language it understands and Logitech makes sure the identifier of their wheel meets this standard and can be identified, and that the buttons names and funcions fall into the spec.
For instance perhaps the PS3 can accept 32 buttons with on off states and 4 axises with 1024 states of resolution. Button and axis names must be included in identifier info and be less than 12 characters long.
Logitech says "yup, all our stuff falls within those paramaters, it's thus compatible with PS3 and thus any game on the PS3 can use it".
At this point we have covered a very basic example of how a peripheral map would be done in a high level generic method but hopefully it gets the point across.
Here you can see why it's almost impossible to "accidentally" delete a button from functioning because you would have to go delete the whole entry for it and input maps exist in an area outside of the modules responsible for coding game functions. Even if you accidentally hit the delete key or something and changed "Input1" to "nput1" the debugging process would catch that the variable nput1 was not initialized anywhere and through an error.
Suffice it to say, accidentally deleting functionality cleanly is VERY hard to do... I related it in a previous post to accidentally removing a room from a building without damaging any of the rooms around it, it's just almost impossible to do without getting caught in the degbug process.
Most people understand that there is a lot of code in games, however what many may not realize is it will be segmented off into its own little areas (like seperate pages of a website) and working on one does not in any way necessarily change another.
When you make a change to the physics engine module, you don't touch the peripheral mapping (as all it does is pass arguments to other modules) and this is why it makes no sense that the general idea "the code changed" would result in buttons not working. Again it seems people are aware of a general idea that things can accidentally affect other things, but there are defined areas of a program in which nothing would affect it. Just like editing pages in a book would never cause the index to suddenly get a misspelling. It might through off sentance structure or make run on sentances, but the changes are isolated to that area.
Now in some areas where communication between modules exists, an output value might be accidentally changed breaking something -let's say in the physices module a variable is dimentionsioned as a float but later changed to an int. If this value is passed to a module expecting a float but recieving an int, this might cause a problem in the module that's not changed. Howver this makes no sense for the peripheral map pertainig to buttons as that's a one way street of information. The peripheral map passes arguments out when it comes to buttons so that's why it's unreasonable to believe this is just an accident or code somewhere else tripping up the controller code.
No as for RA menu, above I detailed the basics of how to handle user configuration of buttons... as you will note, any button that can be accessed can be reassigned to any function as long as it's the right kind of button (ie it would be kind of silly to map an on/off button to an axis) so in order for the RA menu to not work when assigned to a button that does work for other things, a special exclusion would have to be programmed in.
Something that, after all inputs are mapped, says "If controller is G27 and Input1 controls FunctionRAMenu then Input1 controls null". Basically you don't just end up with a function that doesn't work on accident if the button works for other things and that function can be programmed to a button (and we know it can because it is doable on all other controllers).
As for "it's Logitechs fault, they should be changing the wheel" again, they would have checked everything is by the books when making the wheel "Playstation 3 compatible" and the fact the wheel works in so many other games kind of proves that they have done so. The only way it doesn't work is if PD does something fishy like they want to make sure the wheel doens't provide an "unfair" advantage to wheel users over controller users. I quote "unfair" because what they are basically saying is "we program our controller users in such a way that shifts take X amount of time, even though in reality you can shift faster with a clutch and stick, we want the wheel to nerf shifting with a clutch so it's on par with controllers, not better like it should actually be".
Now that's just what I am getting from what PD has said, maybe it's something else but Can't for the life of me think what it might be.
So if we go with that scenario, they are essentially asking Logitech to go back and change their perfectly fine, perfectly compatible hardware to support their desire to keep controller and wheel users on even ground (which in and of itself is an artificial nerf - I can see why you would want to what with global leaderboards and all, but still). Assuming Logitech COULD change their wheel without breaking support for other games (which is entirely possible they can't) Logitech is in a very fair position to say "WTF PD, our wheel works great and even works in much louded games like iRacing perfectly and you want us to go make changes that involve a lot of work (not sure if G27 can even support a firmware flash) to make the wheel crippled just right for how you want your game to work? Sorry that's unreasonable to do after the fact like this". So PD goes off and works with someone on new IP that isn't already out in the market and can be designed from the ground up to support their specific (non standrad) desires.
So that is why I find all the evidence put together pretty unsurmountable in terms of changes being intentional... becuase of how it all works, I can't imagine any way that it could be accidental and still turn out so exactly how it is.
And that's also why it's unreasonable to blame Logitech or wheel makers in general for not bending to non standard special requests from game makers especially in situations where it's potentially quite hard or impossible to do so especially in light of the fact the problem lies not with the wheel (as is evidenced by how well it works in top notch games like iRacing) but in how the game dev wants to make an artificially balanced playfield for controllers and wheel users.
Now I have laid it out in pretty specific manner... this is not just saying "well the code changed" or "I have heard of times when code in one area effected code in another area". I am telling you from my own experience and understanding of the fundametals of programming, that this is why I believe everything points to an intentional nerf.
If you want to refute this, please make sure to do so with ACTUAL detailed reasoning and explanations of why you believe what you believe. Not just "Well I dunno... I think it might be diferent elsewhere, coding is complicated and I have seen weird things happen before".
Contrary to some comments, I more than welcome difering opinion on the subject, but only educated difering opinion. If you don't really understand the subject and it shows in how you phrase or talk about the issues, you will have to forgive me for not giving you credit for your ideas because anyone can say "I dunno, it's pretty complicated" but it really only matters if someone can say "I think not and here is exactly why" especially if that exactly why holds up logically.
And I will add that, no just buying a lot of controllers or having played games for a long time doesn't mean you understand the workings... it means you have a lot of empirical evidence, but if you don't have the understanding of the workings, you have only suspect information. Remember empiracle evidence is what made people believe the earth was flat and the sun went around the earth... the same can come up easily in technology discussions. Remember a lot of how tech works is hidden from the user on purpose.
