COD Bugtracker

[Dickie]

Fuck Vranac you actually voted against it. Go fix that you dick.

[Dickie]

Artists reply is extreme. They want documentation, a photo not enough. Ffs they are ON the 3D model on the Hurricane!

[Bubi]

Artists reply is extreme. They want documentation, a photo not enough. Ffs they are ON the 3D model on the Hurricane!

I do appreciate the work the TF guys do, but there is what is reasonable and what is unreasonable for the request being asked. We are talking nav and landing lamps, not something like FMs for the Queens sake. Whats the big deal here not trusting period pictures?

Im reluctant to do all these push ups if they won't use what we have as providence. Like I have all those time period documents for every aircraft, not. In court these pictures would be enough circumstantial evidence to convict a criminal of being at the scene of the crime.

In the company where I work, we develop the ECAD software engineers use to design electronics, R&D has clever little tricks by setting the status on the change requests to values that buy them infinite time to work or avoid issues. Another "no" mechanism that tries to save their resolution statistics. Its a constant battle we must wage on the behalf of our customers. Its called the "ivory tower syndrome" internally or "black hole" by customers.

[Vranac]

Fuck Vranac you actually voted against it. Go fix that you dick.

Yes, and if you noticed varratu also voted against and he is versed very well with 109 history and mechanics.

And by the way I stopped a huge number of Russian speaking pilots voting against your proposal for the gunners.
I explained them what you want so they didn't vote. You would have some 15-20 negative votes from them only
if I didn't do that.

[Thaine]

Fuck Vranac you actually voted against it. Go fix that you dick.

Yes, and if you noticed varratu also voted against and he is versed very well with 109 history and mechanics.

And by the way I stopped a huge number of Russian speaking pilots voting against your proposal for the gunners.
I explained them what you want so they didn't vote. You would have some 15-20 negative votes from them only
if I didn't do that.

Why, by the power of the deathstar, would they do that? Rookie gunner -> hardly hits everything; Ace gunner -> shoots very accurate. That should be self explanatory.

[Vranac]

Why, by the power of the deathstar, would they do that? Rookie gunner -> hardly hits everything; Ace gunner -> shoots very accurate. That should be self explanatory.

A lot of them fly bombers exclusively. They were concerned that would make gunners even worse. Gunners are practicaly useless when you fly a bomber. We don't know on what level the game is setting the gunners on a human flown bomber.

[Pitti]

Yes, and if you noticed varratu also voted against and he is versed very well with 109 history and mechanics.

This has nothing to do with history and mechanics. Technically it works fine it is just the inverted key/button assignement.

[Vranac]

Yes, and if you noticed varratu also voted against and he is versed very well with 109 history and mechanics.

This has nothing to do with history and mechanics. Technically it works fine it is just the inverted key/button assignement.

You have some proof for that ?

And again, I think there is no one in ACG at least, who is changing planes more than I do. And I don't have any problem with PP.
If they change that I'll have a problem because I manage PP "automatically" without thinking about it.

[Robo]

Implementing landing lights, nav lights etc would be extremely difficult I am afraid. Very much like the mirrors for RAF fighters - don't hold your breath even if you provide full documentation (e.g. cockpit switches).

I appreciate the team effort in getting some annoying bugs out of the way, but I don't see any reason at all to force the opinion on ACG members. I mean if Vranac doesn't like the feature he's free to vote against it.

[Bubi]

Implementing landing lights, nav lights etc would be extremely difficult I am afraid. Very much like the mirrors for RAF fighters - don't hold your breath even if you provide full documentation (e.g. cockpit switches).

Like I said, I live interfacing with customers and developers every working day. I know a rope-a-dope when I see one. That being said, what the TF group has done and continues to do is freaking amazing and mucho appreciated. So I won't demonize them for not doing my enhancement request, but lets just be reasonable about what kind of info is really needed from the requestor and not use lack of documentation as the reason to shelve it. I get that its significant work to do these, but nothing more than pictures should be sufficient, especially when IL2-1946 already had these.

This is what I would expect:
a. Change the change request to the next state from Submitted to More-Info. Then detail what more info is needed and why.

This is where we are with #610, but the more info requested isn't reasonable or explained why the extra level of work is necessary. It leaves room for customer dissatisfaction and log jams the processing. If its not likely going to happen, this is the time to explain that and treat the customer with respect for the effort they put into submitting the issue in the first place. If not, hence the "ivory tower" tag.

b. Once the data is supplied, change to the state to Checked-In to signify the issues are going to be worked, or Rejected if not.
c. When the work actually starts, the state changes to Characterized indicating the issue is currently being worked.
d. Give an estimate of the work and provide the proposed or planned release date/release.
e. Change state to RTM (Release To Manufacturing) when the fix is ready to go into a patch/release.
f. When completed change the state to Done.

This is an abbreviated illustration of how the big-boys do it. The black hole occurs when the system is not accurately employed or updated.

So what needs to happen next is to either reject the request or set a reasonable more info expectation for requested supplied data. But to signal a willingness to perform, but give an unreasonable level of documentation for more info back onto the requestor tells me that theres some combination of:
- a manpower problem
- a lack of understanding of exactly what is actually needed for the job at hand
- just another form of issue rejection by requestor exhaustion.

Come on Team Fusion, lets just do it. Everyone wins.