Did PD intentionally nerf the G27 to artificially favor the T500?

[Noctophobia]

Hmmm, yes. I'd say next, turning left will be disabled on the G27 - can only turn right. Still should be okay though; you could do a 180 and just reverse around any left-hand corners.

Seriously though, I agree with anybody raising suspicion with relationships between two separate commercial entities. The reality is, PD have not done their best, nor made much effort, to support the most popular wheel models.

I just was watching vids and saw someone asking it without an answer, rather than going off why not simply answer?

Or you are just trying to act cool? Not funny anyway.

 

[alexgontijo]

I agree with the topic and I'm very sad with my G27.

I had a DFGT and sold to get a better wheel. But how unfair life is... the better one isn't compatible and only works by pity. Now I'm considering selling my G27 to buy a Fanatec.

Logitech should do something!!!

I wish I could combine DFGT wheel and the G27 pedals!

 

[Zoom!Zoom!]

NM they are wired different.

 

[alexgontijo]

I've googled and someone said it has different pins, although the connector looks the same. So it doesn't work.

 

[LordVonPS3]

Someone with a little ingenuity could devise a pass-through dongle to read all USB data from the G27 and repeat the data but with a different device identifier / button mappings / FFB instructions. Perhaps mimic the new T500 wheel when it arrives.

Of course the dongle would need to do the same in reverse (i.e. remap PS3 + GT5 game instructions for the other wheel ident back into instructions the G27 can understand).

To do this you'd need both wheels, then you'd need to build a USB pass-through monitor just to see what traffic is being sent in some typical races. After some analysis it should then be possible to map the instructions closely.

Just use a PIC or Z8 attached to a USB controller chip and a couple of ports, any lag would be measured in nanoseconds / microseconds (negligible). It would be a nice little project for someone like Ben Heck... A bit of hassle perhaps but should be very possible to do ASSUMING the traffic is largely compatible and isn't encrypted.

Polyphony could patch support and make life easier on everyone though.

 

[Devedander]

I agree with the topic and I'm very sad with my G27.

I had a DFGT and sold to get a better wheel. But how unfair life is... the better one isn't compatible and only works by pity. Now I'm considering selling my G27 to buy a Fanatec.

Logitech should do something!!!

I wish I could combine DFGT wheel and the G27 pedals!

They did... they made a quality controller that meets the standards set by the system and the communication method they use. Essentially they did everything right.

At this point saying Logitech should do something would be like if Toyota made a car with a completely stanards compliant gas tank, then Chevron gas stations produced a fill nozzle that had sensor that specifically blocked working with Toyota gas tanks and then saying "Toyota should do something about the gas tanks on the millions of cars they have sold!"

PD really should do something... like stop playing dirty poker.

Someone with a little ingenuity could devise a pass-through dongle to read all USB data from the G27 and repeat the data but with a different device identifier / button mappings / FFB instructions. Perhaps mimic the new T500 wheel when it arrives.

Of course the dongle would need to do the same in reverse (i.e. remap PS3 + GT5 game instructions for the other wheel ident back into instructions the G27 can understand).

To do this you'd need both wheels, then you'd need to build a USB pass-through monitor just to see what traffic is being sent in some typical races. After some analysis it should then be possible to map the instructions closely.

Just use a PIC or Z8 attached to a USB controller chip and a couple of ports, any lag would be measured in nanoseconds / microseconds (negligible). It would be a nice little project for someone like Ben Heck... A bit of hassle perhaps but should be very possible to do ASSUMING the traffic is largely compatible and isn't encrypted.

Polyphony could patch support and make life easier on everyone though.

This would be an interesting project and I am thinking you are right, while we shouldn't even have to bother with this, it shouldn't be too hard and I really doubt the communication is encrypted... my bigger concern would be that with the greater resolution or travel of some parts on the T500 the translations might not go smoothly...

If I were more up to snuff on this kind of stuff I would try to crank one out cheap just to spite what I feel is PD's attempt at dirty play...

Imagine "$300 for G27 + $10 for passthrough dongle or $600 for T500 + ???$ for HGate shifter you choose!"

And yes PD should really patch in support (or more accurately patch in a removal of the nerfs)

 

[niky]

I would not put it below PD to favor a company because of endorsement deals and other technical tie-ups. Whether it be by putting their cars on the cover of the game or giving them more exposure, or whether by putting their product's name on a manufacturer's vehicle, controller or etcetera. But it'll take a lot more than this to make me believe they are trying to diss Logitech in order to support Thrustmaster.

The problem is the RA menu never worked at all anywhere for G27... it doesn't even bring up the menu... let alone lock you out of making changes. The buttons literally goes dead when you set it to RA menu, but it works fine for every other option that can be set and up until the last patch, no controller config had it limited in any way BUT the G27 and the G27 didn't just have it limited, it wouldn't even bring up the menu.

And again at some point IF such code existed (which it makes no sense that it would have from what we can see) it still would have had to have something in it specifically to affect the G27 only since no other device suffered RA menu nerfing before 1.05. Remember at the same time the G27 simply couldn't bring up the menu, the controller sitting right next to it bring the menu up just fine. That right there tells you the G27 is being singled out to not be able to use the RA menu.

So in short, no that doens't make any sense either.

You're assuming that the code is merely to deactivate. What if the code is there to activate the RA, and has to be mapped specifically to each button? It's very weird of PD to have it... (but from the DFGT issue, we saw it was there)... but apparently, they have codes that are sensitive to which button you input them from. Not the way you or I would do it, right? We would simply say: "If someone presses the RA button, whatever it's mapped to, we will either recognize it or not, based on whether we need to, irregardless of what controller is being used."

PD, obviously, didn't. And yes, it doesn't make sense.

See where I'm getting at? How can you have input from one device and one device button only recognized when all other devices don't get it? This means that said input within the game program is case-sensitive. Otherwise, they wouldn't need the kill switch itself to be button specific... something which I find utterly bizarre.

Again: Needless complexity for a simple system. A system, I agree, that should be simple, and which other companies execute without problems.

The 4 wheel buttons are not necessarily L2/R2, they are 4 specific and different buttons. They could be anything. See you are thinking that every button on the wheel must correspond to a button on the standard controller... it doesn't. While I don't know the exact names, they are quite likely just Button1, Button2, Button3 etc (see that earlier link on USBHID peripheral standards) all the way up to however many buttons their are. No button has to be any sepcific playstation button. For instance the 4 black buttons happen to correspond to the 4 buttons on the DS3 face, but they don't have to, the game dev can choose whether to map the buttons at all, and if mapped, what to default them to. The dev also chooses whether they are forced to that or they can be changed.

So if PD wanted to, the 4 black buttons on the ****er coudl easily be L3, R2, Select, and X or any other combination by default. On the wheel there is no actual "L2" it's just what PD happened to default it to.

In GT5P it was setup so that whatever the top button was mapped to, the lower ones were duplicated to that. It effectively made each side one big button with 3 lumps. This is not because the buttons can't function seperately, it's just because PD basically said "Allow assigning to top button, duplicate assignment to bottom buttons".

What PD has done now is not mapped those buttons in the peripheral map, they are dead to the game and do not respond to anything at all.

So in the chain of communication this is what looks to be happening:

Wheel tells OS I have buttonL1, ButtonL2 and ButtonL3 (3 buttons on the left side) and the OS says "OK I am passing these to software as Input20, Input21 and Inpu22 (numbers are not actual, just representative) and passes access to them off to GT5.

In GT5P PD did as I said above and just limited the use of these buttons to duplicates of Input20. In GT5 they have effectively removed the part that says "duplicate Input20 to Input21 and Input22" and just said "map Input20 default to L2" and stopped. They have removed any mention of Input21 and Input22, and did not make them functional at all.

This is not function specific, these buttons literally work for nothing as do the outide red buttons on the shifter. Again these DID work (so at one point were coded) and that coding has been removed as thhey no longer work for anything.

This was all covered in the OP, if you re read I laid out the details of what works and doesn't and the chain of events that make it pretty indisputable their functionality was taken out, not just accidentally never implimented.

Here we once again run into the wall of believing that GT5 is a direct development of GT5P. Which it is not.

I'm not going to tell you GT5 is a ground-up game, as you think I'm trying to say.

It's more like this: PD have always claimed that GT5P was built off of an earlier beta of GT5 (in other words, not the beta that they were currently working on at the time it was released).

In other words, they took the game engine, slapped together some events, added some features and compatibilities and published it. It took them long enough to do all that that the official line became that GT5 was at a much later stage of development than GT5P at the time of release.

Now, your concept of how it goes is like this:

GT5beta1 -> GT5beta2 -> GT5Prologue -> GT5beta4 (update 1 for prologue) -> GT5beta5 (update 2) -> GTbeta6 (final update) -> GT5 Time Trial -> GT5beta7 -> GT5.

When it could just as easily have been this:

GT5beta1 ->
GT5beta2 (testing still purely with DFGT and DS3) + GT5P (add compatibilities with non-standard controllers, add tuning system... which is even more comprehensive in terms of transmission tuning than GT5 1.05) ->
GT5beta3 + GT5P (port some tire physics updates to GT5P and some tracks and cars) ->
GT5beta4 + GT Time Trial (add interface and controller compatibilities) ->
GT5beta5 -> GT5 (add new interfaces, add non-standard controller compatibilities, etcetera)

Everything in parenthesis is conjecture. But according to marketing, GT5P was built off of an earlier beta of GT5, and polishing it up into a sellable product did take a little time.

Apparently, when they mapped the G25 and G27 buttons on GT5P, they did it in a slapdash manner. What is unknown is whether they actually did this before or after they budded off the beta to be packaged as GT5Prologue. But considering they have always promised support of the DFGT, it stands to reason that it's this wheel they did playtesting during development with. (Yes, they should have done complete testing with everything... but again... seeing all the other issues... we can assume that there are many things they neglected to test...)

Again: I have never said GT5 was built from the ground up. But just because GT5P and GT5 are built on the same game engine doesn't mean they are the same game. The user interface is different. The tuning interface is completely different, with some functionality removed. While it would make sense to have copy-pasted G25 and G27 functionality from GT5P, it's not entirely non-possible for them to have recoded it anew.

Now you have decided $600 for the T500 is ridiculously high prices ESPECIALLY since it doesn't even come with any kind of stick shifter (no H gate and not even a sequential stick!).

It's a hard sell right? Some will buy it, but it's a hard sell...

I've never thought it to be practical, and have never said otherwise.

It's made little easier by the fact taht the closest available competitor is missing some functionality. Not all the buttons work, the FF is apparently not changeable, you can't call up RA menu. None of these are critical deal killers... some people will still make the call "even with the flaws, $300 for a G27 is a better value than $600 for the T500 without even a stick shifter.

But some will say "Screw it, do it and do it right. $600 isnt' THAT much money in the big picture and I don't have to put up with annoying things like not being able to assign every function like wipers and lights and buttons that don't work or having to have a controller around for RA menu"

As I said before, some people openly admitted they were paying $200+ for the SE when the normal game was available for $60 simply becase they were excited about GT5 and now that they finally got the chance to buy it, they were doing it right.

You and I may not be swayed by such thing, but there are some who will be. Look at it this way, would you NOT want EVERY advanatage you could get while trying to market a $600 wheel against a $300 competitor that commes iwth an Hgate? Surely you would... I would even bring up better quality paint or a better cable management system if it exists on the T500... literally make the check list as long as possible with thing that favor you no matter how small.

NOW think about this... what if the G27 was FULLY functional... I mean every button on the wheel works, every function in GT works, FFB fully tuneable... suddenly the G27 actually has a few legs UP on the T500... more buttons available means you can actually program MORE into the G27 than into the T500 (note the T500 appears to have only 6 face buttons and a Dpad which is a pretty low count).

So when people ask on the forums or of their friends "which should I get? G27 or T500" the answer would then be "Dude! The G27 does EVERYTHING the T500 does, it has MORE buttons so you can program every feature in the game, it COMES with an hgate shifter and it's half the price of the T500 before even the shifter! Unless you REALLY want that better belt drive motor or something, definitely go G27. I mean mine works perfectly in every way for GT5 and I don't mind the noise at all and the FFB is plenty strong enough for me."

Now compare that to what we have now "Which should I get?" answer "Well I think $300 for the G27 is a better deal, but I have to keep my controller around and awake just to access the RA Menu, I can't program all the features onto the buttons which is kind of annoying and embarassing when showing off this cool game to my friends only to say 'oh yeah you can turn the wipers on and honk the horn! But I don't have those buttons mapped because I ran out of buttons, but you can do it!' and the FFB is a little too strong/weak for me and I can't make it really how I want... honestly it's just too unpolished an experience and I can't afford the $600 for the T500, but if I could, I might just do it to make my experience perfect."

See how nerfing a few features could quite easily swing some sales?

As I said before, I doubt they are trying to get G27 owners to upgrade to T500 out of frustration or anything, but when it comes time to buy that next wheel (or first wheel) they want the comparison chart to favor the T500 as much as possible to offset the price tag.

Think of how comparing GT5 against FM3 they put a lot of bullet points out there like weather, 1000 cars, time change etc... even if those things had major caveats like 80% standard cars, weather and tim only on some tracks and only in limited ways on many... it doens't matter... bullet points sell. It' marketing.

Basically the T500 has it's own selling points already, but what marketer wouldn't want MORE selling points... even if they are minor? If Toyota could somehow screw Honda into using 1mm thinner door panels do you not think they would so they could say "and our door panels are thicker than Honda's making them more dent resistent and making the whole build more solid"? I mean 1mm thicker doors are not a huge selling point on a $30,000 purchase but if you were a salesman, which would you rather have:

Checkmark next to selling point "thicker door panels"

or

Not have a selling point "thicker door panels"?

It lilke asking "would you like 25 cents or like to not get 25 cents?" It's hardly a big deal, but given the option who would ever choose "not get 25 cents" over "get 25 cents"?

Or imagine we are both selling our cars and I have the opportunity to (without getting cought) put a little dent in your cars hood. Nothing big, still runs fine and all... but it's something a potential buyer will probably notice...

If I did that, it's nt like a little dent is a huge deal, but it might just be what puts them over the edge to buy my car...

Are you seeing where I am going here?

Of course. Your analogy isn't perfect, but there are similar situations with Microsoft Sync, Satellite Radio and other things in the auto business.

I will admit that it's a point in favor of the Thrustmaster, but again: there are other much bigger points in favor that PD would not be called out on... points that would mean much more to most people than button mapping.

BTW I am going to go ahead and be blunt here again, I understand you are busy modding arouond the forum and so it may be hard to follow this very techincal and long winded discussion in much detail, but it's kind of aggravating that you are continuing so adamently with your position when you have clearly not put much time into understanding the subject at hand especially when I am doing so much to try and lay it out for you in as detailled a manner as I can.

I mean you don't know what the details of the missing function that I put in the OP (which I suspect if you did might have saved a LOT of time and explaining) and you didn't even know the T500 costs $600 sans shifter...

Now not to be rude, but how would you feel if someone came up to you from basically a position ignorant of the facts then proceeded to ignore all your attempts to educate them on the situation and proceeded to argue you over and over from basically the same stance asking you things that they clearly wouldnt' have to had they bothered to read what you laid out for them before?

The places I run into this most in regular life are politics and religion... someone will constantly argue that a politician is like this or like that when they actually have onlyh a passing knowledge from a few TV blurbs about said politician and when you give them the real story on the politician they just kind of ignore it and keep asking "well what about this!" because it' what they feel must be true based ontheir emotions despite the fact you just said "he never did that thing" a second ago...

I am going to say again, I would really appreciate if, rather than what amounts to (again going to be blunt) wasting my time by popping in to put the burden of explaining the situation to you, you would give a little effort to reading what I have carefully laid out to help you help yourself before debating it further with me.

If your mod responsibilities make it impossible, I totally understand but I would also ask that you respect the truth of the situation there also and perhaps recognize your hat might best not be thrown in the ring considering you haven't had the time to put the effort necessary into it to be respectful of others time and effort involved? I mean I don't go into mac forums and try to question mac user about their issues while ignoring the FAQs or documentation provided about said subjects...

I mean post get closed because someone couldn't be bothered to look around a few posts before posting a question and knowing you don't have the time to get educated on the subject, but then posting theories on said subject repeatedly is somewhat akin to poting false information. Pretty much what I am asking for is that you recognize the amoutn of effort I have put into this, and put a reasonable amount of effort into making sure what you put forth as ideas or theories aren't already covered, debunked or easily ruled out through a little research on your end... kind of like please try using the search feature before making a new post so you don't make the mods close an uncesarily large number of duplicate thread kind of deal?

I'm not going to take offense to the idea that I don't know a whole lot about peripheral development, but I do have enough programming background to look at what's happening with these peripherals and say: "Look: PD is doing it wrong... and not just in this specific case."

I have not ignored anything. I see you positing how other developers do things and how PD should be doing things. You are saying: "This is the only way it can be done, thus they are doing it this way."

I am looking at all the different control issues that have come up between GT5P and GT5, and I see a pattern in which PD are not doing things in the most straightforward and sensible manner. At which point, I am lead to believe that there is something fundamentally wrong in the way that they approach wheel controllers and controllers in general.

Now, of course, if you want to cover up a murder wherein you poison someone's Tylenol, you'll do a whole bunch of other bottles and try to hide the murder as part of a tainted drug issue. But mucking up a whole bunch of programming decisions on purpose simply to theoreticallysell a few more T500s, when all of these bugs are, in fact, negatively affecting GT5's reputation and turning away a few buyers, seems a bit overkill, doesn't it?

 

[JGW]

I think it's safe to say....PD half assed this all the way. Strange decisions occur though out the game. What used to be fun is now something....not as much. Still fun, but...diminished somehow....solely based on their weird ass logic on specific items.

It's almost like they've had their sight on the ball the so long that they've lost the forest for the trees.

The King is dead....let us await the future king

 

[Devedander]

You're assuming that the code is merely to deactivate. What if the code is there to activate the RA, and has to be mapped specifically to each button? It's very weird of PD to have it... (but from the DFGT issue, we saw it was there)... but apparently, they have codes that are sensitive to which button you input them from. Not the way you or I would do it, right? We would simply say: "If someone presses the RA button, whatever it's mapped to, we will either recognize it or not, based on whether we need to, irregardless of what controller is being used."

PD, obviously, didn't. And yes, it doesn't make sense.

You kind of lost me there... I think you are saying that globally RA menu is disabled and in each area of the game, a special function has to go turn on access to RA funciton? Is that what you are suggesting?

If so first you are right, it makes no sense from a practicality point of view and second it makes no sense from the point of view that PD would have had to TURN ON RA menu in the license tests that they clearly didn't want to have them turned on in and that PD would have had to TURN ON RA menu in online rooms overriding the rooms specific limits.

That's just one thing... trying to wrap my head around why and how sommeone would go about such a needless complex and error prone method to doing something sets off every alarm that says "no way".

I mean look at what's happening right now... when you go into an online lobby, RA functions are disabled so you can't override the room settings, but then you leave and go into a normal race and they are still disabled...

This clearly shows that there is no function turning RA on, it's a function that exists in some areas to turn RA off and in fact the problem is that there is then NO function to turn RA back on so it's left off when it doens't need to be.

Think through how you would accomplish this... there is only one way that makes any sense at all. It's happened to me plenty of times as well as every coder I am sure and it always works like the same way: Ooops, need to limit access to that feature when you are on this screen, I will just put a disable at the top of that module. Test - yup, featuer disabled on this screen nice. Compile. - Later - crap... forgot to turn the feature back on at exit of that function.

Trying to imagine how it would work if I had a global off set for this function, then turned it on in ever module and only for every device but one, then went back in and coded it again to turn off in some modules and then have it some how not turn back on in another module after that it should be on in when (if you look back) I have a turn on function in each module already... that doesn't make any sense... I would have to work pretty hard to pull it off let alone accidentally make it.

So no the eveidence goes entirely against that being a possibility...

See where I'm getting at? How can you have input from one device and one device button only recognized when all other devices don't get it? This means that said input within the game program is case-sensitive. Otherwise, they wouldn't need the kill switch itself to be button specific... something which I find utterly bizarre.

Again: Needless complexity for a simple system. A system, I agree, that should be simple, and which other companies execute without problems.

No... I don't see... you lost me here again... can you give more detail about which button and device you are talking about and when it does doesn't work? I am confused what you are trying to say... Are you still talking about RA menu or are you talking about R3 and L3 or something else? I am lost...

Here we once again run into the wall of believing that GT5 is a direct development of GT5P. Which it is not.

I'm not going to tell you GT5 is a full standalone, as you think I'm trying to say.

It's more like this: PD have always claimed that GT5P was built off of an earlier beta of GT5 (in other words, not the beta that they were currently working on at the time).
Apparently, when they slapped on the (limited) compatibilities with G25 and G27 buttons on GT5P, they did it in a slapdash manner. What is unknown is whether they added compatibilities before or after they budded off the beta to be packaged as GT5Prologue.

I see what you are saying... a code branch. Kind of like how evolution doesn't say people came from chimps, but rather that people and chimps both came from an earlier shared ancestor.

That is entirely possible and in fact code branching is quite likely.

But there are a few reasons for that not being a reasonable explanation for this:

1 GT5P was in development for a long time and a lot of work over time was put into it. It's HIGHLY unlikely that they code branched GT5P off a very early GT5 and did parallel development on both for so long... it would literally possibly halve the task force for each for years only to provide support for GT5P beyond what was needed... Impossible? No. Highly unlikely? We are back in the realm of monkeys, typewriters and shakespear again.

2 Even IF this were true, the foundations of both games obviously go back deep enough that the peripheral input support is the same... in fact peripheral mapping for any game on a standardized closed system like PS3 with a USBHID standard device is the same from the ground up. Again it's unbelievably unlikely that the code that succesfully mapped L3 and R3 in GTP could not do the same in GT5.

3 This further makes no sense because they can map every button other than L3 and L2 off the standard DS3. There is nothing special about L3 and R3 that would make it any challenge at all to map when you have mapped all the ther buttons succesfully. To suggest that is to suggest that someone typed 1, 2, 3, 4, 5, 8,9,10 and only skipped 6 and 7 becuaes while they figured out how to push all the other number keys, they coudn't figure out how to push 6 or 7.

No... again doesn't pass the sniff test let alone occams razor.

I would personally lay long odds that GT5 can be traced back through some late version of GT5P. If any eventual difference in code branching took place I would say it looked something like this:

GTHD->GT5P Spec1->Spec2->Spec3->Split to TT and GT5.

It just makes no sense that you would take something between GTHD and GT5P and parallel develop two games (GT5P and GT5) sperately off that and EVEN IF YOU DID, button mapping hasn't changed since the PS3 launched... it's done pretty much the same for every game out there including G5P and GT5 and it's so unlikely as to be dismissable that figuring out how to map L3 and R3 in GT5P isn't at most a copy paste slution for GT5.

Of course. Your analogy isn't perfect, but there are similar situations with Microsoft Sync, Satellite Radio and other things in the auto business.

I will admit that it's a point in favor of the Thrustmaster, but again: there are other much bigger points in favor that PD would not be called out on... points that would mean much more to most people than button mapping.

I am not arguing that but what are some of those points in your mind? Ones that could be nerfed, leave plausible deniability and not draw a lot of negative press towards PD and GT5 or alienate existing G27 owners who would rather skip the game than spend another few hundred dollars on a wheel to play it.

I'm not going to take offense to the idea that I don't know a whole lot about peripheral development, but I do have enough programming background to look at what's happening with these peripherals and say: "Look: PD is doing it wrong... and not just in this specific case."

I have not ignored anything. I see you positing how other developers do things and how PD should be doing things. You are saying: "This is the only way it can be done, thus they are doing it this way."

What I am trying to say is that there is no way I can imagine other than this that isn't so convoluted and unlikely as to be dismissable. If you can think of any way and explain it in reasonable detail I would love to hear it. I am far from infallible... but I need more than generalities and suggestions that something might be different or complex somehow... I need a reasonable explanation with enough detail to show the actual path you think might have taken place.

If you see a broken rock next to your car window and your stuff is misssing from your car, there are countless ways it might have gotten there... but there is only one likely explanation and it's so much more likely than any of the other reaons that you can pretty much write off anything but "someone smashed my window and stole my stuff".

Now if someone were to say "well I don't know... I have seen a lot of rocks in a lot of places and I have seen broken windows in houses and offices before... isn't it possible the rock rolled here from somewhere and maybe a wind or bird broke your window and somehow moved all your stuff from your car?"

You would also pretty much write that off wouldn't you? Just a little thought shows how those are pretty much unbelievable ideas and that's kind of what has been happening with all the theories you have put forth... are they possible? I suppose... but with a little logic and thinking through they make so little sense as to be completely unbelievable. I mean your theories would be more a conspiracy theory than what I have put forth by a long shot... to end up with so many perfect accidents all at once the way they have that avoid detection and breaking thing completely?

No...

I am looking at all the different control issues that have come up between GT5P and GT5, and I see a pattern in which PD are not doing things in the most straightforward and sensible manner. At which point, I am lead to believe that there is something fundamentally wrong in the way that they approach wheel controllers and controllers in general.

What are you thinking of specifically? I ask because there is a huge difference between design decisions (ie xp locking progression) hardware limitations (ie choosing jaggy shadows in order to achieve dynamic time of day) and basic coding issues (ie not being able to mape a button that you have shown you know how to map in another - if not prior version then very close version - game).

You have to be able to understand and realize that while bad decisions in any of those areas can result in "that's done wrong" one is not indicative of another.

For intance to relate the jaggy shadows to not mapping a button right would be like saying "My carpenter decided to put regular shelves in the corner where obviously you would want a lazy suzanne therefore I assume he also may be dumb enough to not know which way a screw tightens".

Now, of course, if you want to cover up a murder wherein you poison someone's Tylenol, you'll do a whole bunch of other bottles and try to hide the murder as part of a tainted drug issue. But mucking up a whole bunch of programming decisions on purpose simply to theoreticallysell a few more T500s, when all of these bugs are, in fact, negatively affecting GT5's reputation and turning away a few buyers, seems a bit overkill, doesn't it?

Honestly how badly are they negatively affecting GT5s reputation? Who has been convinced to stay away from GT5 based on these issues? GT5's image is pretty heavily tainted already on a lot of fronts, in the big picture this is a pretty minor hit to GT5 especially given the plausible deniability that many buy into... I mean very few people even realized the issues at hand and most of them wrote them off as frustrations...

But a frustration in the back of your mind for a long time is a great sales tactic... how often have you bought some nick nack at the store for $20 that totally isn't worth it (maybe it's a little piece of plastic with a hook on it or something) but you know what? It fixed that one little thing that annoyed you for years now...

That's why I have said that this fits squarely into the realm of the perfect crime... it accomplishes it's goal without being so obvious or conspicuous as to cause more damage than it helps... and it was a pretty safe bet that someone like me wasn't going to come along and post something like this... had I not (and no one did) it would be almost perfect.

 

[7HO]

You two still going

I wonder how many other people stopped reading the walls of text pages back

 

[Devedander]

You two still going

I wonder how many other people stopped reading the walls of text pages back

A lot I am sure!

 

[NOS Waster]

I'm still reading. This has seemed to turn in to quite the discussion.
Why couldn't most forum topics be somewhat like this one? It just seems so full of intelligent and thought-out posts .

 

[niky]

Unfortunately only one side of the argument has experience in this sort of software development... So while I know the theory, I am sadly out of date. I am simply trying to play devil's advocate best I can.

The idea is not to come up with wild theories as to how this isn't the case, but to find out if it's as open and shut as all that.

Above, I was talking about the RA menu. The silly thing was that in posited recompile, the disable function worked for every single peripheral except the DFGT. Which doesn't make sense. It should be the same whatever peripheral you use. Meaning that the game module handling the RA menu recognizes different peripherals and has an independent set of... let's say.... permissions for each peripheral. Could this be what's affecting the G27 instead of a button mapping error or exclusion? Whether accidental or not? This is the one part of the whole jog dial / RA Menu brouhaha that still bugs me.

I'll admit, it's highly unlikely that GT5 branches from GT5P at such a fundamental level, but I throw it out there given the possibility that button mapping for alternate (not official) peripherals is tacked on only later, instead of in the beta stages. In other words, they don't do beta testing with anything but the DFGT. Yes, silly and highly unlikely... so I'll have to admit that this is a very long longshot.

One of the control issues I was talking about was the clutch. GT was not programmer to recognize whether it was active or not, leading to ultra fast shifts for users versus other wheels. Again, points to the lack of testing with certain peripherals.

In the end, I will concur that not mapping face buttons in this iteration of GT is absolutely strange considering they were able to do it before... And their inability to give a solution grates for some... But only the timeliness or absence of the supposed "patch" for the issue will tell us if your suspicions on the motive part are correct.

 

[tibiquera]

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.

If you write individual code for each individual peripheral that would be poor programming. Something like: if (g25) {executeg25Code} else if (g27){executeg27Code} etc, would have way too much duplicate code, would be way too hard to maintain and would not support new peripherals. They would write a universal code that covers all bases, and add some exceptions on the code for specific situations like the one you wrote below:

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).

Yes, that is feasible from a programming point of view. But on the other hand, if their goal was to incentive people to buy the Thrustmaster wheel, wouldn't they nerf all wheels? It would take exactly the same amount of code. For example, instead of saying: if(g27){RA = null} they could say if (not dfgt and not thrustmaster){RA = null}. So why just the g27? This code would also apply for the G25 and Fanatec wheels. Plus, if this is an evil scheme from PD, if Logitech were to bounce back and release the g29, they would magically have the RA back since it would bypass PD's condition of nerfing the g27. Again this makes me think it was not intentional, but simply a bug.

And although you're right when saying the code is modularized, you still will find a lot of situations where something affects something else that to you looks absolutely unrelated. The way data flows in a complex system can be quite complex and takes a long time for an outside person to fully understand. From your example of editing a book not affecting the index page spelling, the editing could very well affect page numbering.

Now the second issue I have is the motivation. You said nerfing the G27 would make people buy the Thrustmaster. Now think about how many people this would affect. It would be people who don't have a high end wheel yet or have a g27, are willing to buy a high end wheel to play GT5, are aware the RA function exists, and are looking forward for the RA function so much that they would still be willing to spend an extra $300 just to have it. How many people would that cover? Not enough for you to justify spending time on meetings and coding and testing, as the turnover would be very little.

I for example have a g27 and I only knew about the RA function in this forum, and only knew other wheels other than the DFGT supported it in this thread, and still don't care about this functions. How many other prospective buyers are in the same situation as me? I would venture to say the majority.

 

[7HO]

IIRC Fanatec had to release a firmware update for the Fanatec wheels to be fully functional with GT5 and I think I recall reading that the Fanatec wheels now identify themselves as one of the fully supported wheels in GT5, even if what I wrote is 100% correct (I'm only 60% certain ) it is not evidence that Fanatec was also intentionally nerfed but it is suspicous considering I also read Fanatec sent a wheel to Kaz so it should have been compatible.

As stated earlier in the thread the G25 is not a current wheel so it wouldn't be seen as a competitor.

I agree with your argument that it would only effect a relatively small number of people but keep in mind that the T500RS isn't targeting the casual gamer, the DFGT is. The T500RS is targeting people who are more serious about their sim racing experience like many of those who post on here, it's targeting people who wish there was a console wheel that compared to the top end PC sim wheels but was priced similarly to the current console wheels, it's targeting guys like me who want the best wheel with the most realistic experience for GT5. I would say that only a small percentage of this group wouldn't be aware of the issues with each option available to them.

I'd have to guess that you were not in the market for a new wheel because most people who are would be researching all the pros and cons of each wheel.

That said RA functionality is going to suck with the T500RS since it has less buttons on the wheel than a DFP and L3/R3 are on the base, either RA functions or other functions will need to be mapped to the buttons on the base.

 

[shirakawaa]

Maybe, just for the T500RS the RA function will work by using the D-pad button once the RA menu is enabled. Thinking about it, it's waste to have buttons just for selecting RA options when other buttons could be temporarily used for that purpose instead once the RA menu is activated.

 

[niky]

Maybe, just for the T500RS the RA function will work by using the D-pad button once the RA menu is enabled. Thinking about it, it's waste to have buttons just for selecting RA options when other buttons could be temporarily used for that purpose instead once the RA menu is activated.

Such a thing could also be done with other wheels as well. I recall I used to map "look" to my G25 shifter D-Pad... enabling double mapping would give me the RA menu with those controls without sacrificing the look function.

Of course, even better if you could individually map TCS+/-, ABS+/- and Brake Bias to their own buttons... (which would be perfect with the G27's three face buttons), but I suppose chances are slim...

 

[mark wolf]

G27 has more buttons than G25. Most logical explanation to me would be they haven't properly supported those extra buttons.

I doubt it's intentional. Sounds a bit too conspiracy theory - Ockhams razor. I'm sure it's a low priority on PD's list though.

 

[JGW]

I doubt it's intentional. Sounds a bit too conspiracy theory - Ockhams razor. I'm sure it's a low priority on PD's list though.

In my mind, it IS intentional. There is NO reason for stuff to work in Prologue and not work now. There is NO reason for such buttons to work in other games, yet not this one.....this is all on PD no matter how you slice it.

So yeah, tinfoil hat on and whatnot....whatever you want to say. Those of us that bought the G27 should be offended that they didn't WANT to fully support the wheel.

All other producers support mass market peripherals...from flight sims, racing sims, etc. As a matter of fact, TM got it's edge years ago by allowing buttons to be programmed with keystrokes that (whatever) games might have.

The PS3 OS supports this wheel fully. In this case, PD simply decided NOT to support it and gave BS explanations as to why they won't/don't.

If they had a problem with the way the device shifted (as they claim), they could have still supported and put a delay in the action (button press or shift stroke....which, BTW, they did for shifting into 2nd) for this wheel.

I cannot fault Logitech on this one....they made a device that is fully supported by the PS3 and PC (windows....not sure about OS X) OS.

 

[LordVonPS3]

Anyone tried using a (mini) USB keyboard to see if it's possible to map GT5 buttons to keys?

 

[Destinkeys]

Well, I may be the dream consumer, willing to accept any explanation thrown at me. But you are the consumer nightmare, determined to find deliberate fault no matter WHAT explanation gets thrown at you.

Try this. Try to imagine ONE scenario that results in the situation that DOESN'T involve chicanery. You can't, can you..? Your mind is made up. This isn't a discussion, it's a rant. That the title of the thread involved a question mark is the biggest misinformation on the while damn thing.

I'm sure you KNOW there was a second shooter in Dallas, too...

 

[rexc]

Don't ask me how or from where, but the following is the transcript of a telephone conversation from late last year that may shed some light on this matter.

Hi Kaz, Phil from Logitech here. How are you going ?

Very well thank you Phil.

Yeah, ah, just ringing to say very well done with your game. We're playing it a lot over here. A fantastic effort from you and your team.

Thats very kind of you to say so Phil.

Look ah Kaz, while I've got you on the phone, there's one little thing I'd like to talk to you about. In your next patch release, we're ah wondering if you can include a few lines of code to get the butttons on the G27 working.

Oh, you want us to support the G-series ? Well yeah, thats no problem Phil. If you're happy we can just do it on the same basis as the Driving Force series. Then you guys can use our logo on the product, in your advertising, you know, whatever.

Ah, yeah, ah, see, ah, here's the thing Kaz. We're already paying you quite a bit of money for the Driving Force to be an offically licensed wheel. We don't really want to pay all that money again just to get a few buttons working, if you know what I mean.

But the G-series is a different wheel...

Yes I know its a different wheel Kaz, but ....

... and we don't have an agreement for the G-series.

... we're talking about a few lines of code here Kaz.

Well Phil, like I said, we're very happy to support it on the same basis as the Driving Force series.

Ok, umm, look, ah, Kaz, lets come at this from a different angle shall we. Our customer service department is getting a lot of emails from G27 users wondering when their buttons are going to work. Now I'm sure you at Polyphony are getting emails from these very same people too...

Well with respect Phil, I have to say that is your problem. You are the ones that said that the G27 worked wth GT5 on your website . We've always been very careful at our end never to say that.

Yes, I know you have Kaz, but we're talking about some of your most loyal fans here. These aren't the people sitting on a couch playing a bit of Gran Turismo with a controller. These are the people that went out and spent a couple of hundred dollars on a wheel to get the very best out of your game ...

I appreciate that Phil, but we've never said the G-series worked with ...

Yes I know, I know ... and we don't have an agreement. But Kaz really, does it really have to be this big commercial issue just to get some buttons working ? I mean we talking about a few lines of code here Kaz, can't it just, you know, just happen ? For the fans Kaz, for the fans.

Well unfortunately Phil, it is a commerical issue. If it was just you and me we could probably work something out, but Thrustmaster are involved in this now. They're serious about cracking the top end of the wheel market and they see Gran Turismo as their way in. They've paid us a truck load of money to be an official fully supported wheel, and now you want the G-series to have the same support when you've paid us nothing ...

We haven't exactly paid you nothing, Kaz ....

... nothing for the G-series. Well you can see how Thrustmaster might get their noses seriously out of joint. If suddenly there is a G-series tuning screen in the controller options, well, they're going to wonder just what it was that they paid all that money for. Just to use our logo ? I think they were expecting a little more exclusivity than that...

Well Kaz, thats between you and Thrustmaster, and it doesn't help your fans who ...

Yes, Phil, but again, if we were to give you for free, what we've made Thustmaster pay a whole lot of money for, well, at the very least they will want a substantial refund of their licensing fee, and will probably get lawyers involved. It could all get very messy.

Yes, Kaz, but in the meantime it's your fans who are missing out, all for the want of a few lines of code Kaz.

Now, if you want to license the G-series on the same basis as the Driving Force series, Phil, and I must say that's a very reasonable rate compared to what Thrustmaster are paying, then I'm sure we can get this all resolved fairly quickly...

Well, however reasonable the rate Kaz, you're still asking us to pay a whole new licensing fee just to include a few lines of code to get a couple of buttons working....

.... so thanks for your call Phil, and let us know if you want us to proceed.

Kaz, Kaz, are you there Kaz, Hello ?

 

[ZX636-R]

^^^^^^^^^^ hahahah

 

[ikarys]

I've been a software engineer for 13 years. One thing I've noticed with the hardware is that the DFGT has pressure sensitive buttons.

The G25 and G27 do not (only the DPad).

I can't find information on the T500rs buttons .

This could have something to do with the problem.

Bizarre, but feasible.

 

[dougdoberman]

You two still going

I wonder how many other people stopped reading the walls of text pages back

Not all of us.

There ARE many people out here who aren't afraid of words.

 

[Mr. Boy]

I'll be getting a G27 next week. I understand that some buttons aren't working, but using my Momo wheel has made me accustomed to that. Does all the important stuff (FFB, pedals, shifter etc) work properly?

 

[Delta_Five_Nine]

I'll be getting a G27 next week. I understand that some buttons aren't working, but using my Momo wheel has made me accustomed to that. Does all the important stuff (FFB, pedals, shifter etc) work properly?

Yes. Basically a few buttons don't work and you can't change button assignments, but all the basics work 100%.

 

[Spagetti69]

And the bits that don't work 100% don't work at all. Lol.

Nah, it's good. PD have nerfed the dial on the DFGT to make us feel better.