Patch Notes and OB follow up suggestions

[Pikey]

Hello ED team,

 

So over the last few years we have seen better patch notes. And we know, there's a lot more changes undetailed, under the hood, in each release.

 

We also know that the idea of forum feedback is that iterative changes on the OB can feed into stable release.

 

When the OB version goes public its had, lets call it, 'smoke testing' or even targeted testing. Following from ED's testing community who looked at these items, I think it might be a useful idea to direct the OB crowd a little more after these releases so we could actually look more closely at areas of the sim that changed.

 

Now some of that is done passively, like Matt will make a video on the Harpoon, you see its released, you go up and check it out. That's a form of directed feedback because the feature is fairly big and well ring fenced.

 

What we dont have anything on is the more subtle areas of change. Upcoming, we have potential changes to Damage modelling. So an example would be a new thread, "You will see changes to damage modelling only on these modules X,Y,Z, we would like feedback on this item, especially graphical artifacts, performance, testing in MP as well as SP. Additionally for scripters we have built a new event system reporting the damaged component and would like you to look at that."

 

It's a silly example, but you get the point, it's a little bit more directive. A better example would be on Weather changes, AI changes etc. It's OK to ask for feedback, it doesnt have to point the playerbase towards defects or sing songs of bad performance, it's just saying, 'this has changed, in this way, see what you find'.

 

It's not for everyone. But given the option I know many many people will feedback with eagerness! We aren't blind to undocumented changes. :) For example I can relate Matts interview in October with MudSpike to new API functions I found in the _G table like circleToAll() and lineToAll() and I went ahead and tried to use them, I got most of the arguments figured out but I dont think it's properly implemented, but the day it does, a wee nod or heads up in an extra forum thread to the customer, from the folks on the test, would really really help! The markToAll() explosion of use was spearheaded by the scripting community. Just look at the things we have been doing with it, creating entire game modes, Admin tools, dynamic mission objectives, artillery strikes, AI control....etc. And that's way before folks like HeatBlur, then Razbam and Deka introduced them to their modules. We even laughed when ED fixed the backwards X and y coords and it broke them!

 

I believe the OB release method is fine but slightly under utilised considering the complexity and I sometimes get the feeling the entire community is judged on the contributions of the few loudest voices.

 

There are very very intelligent professionals out there in a multitude of disciplines that could provide useful technical data on quite obscure items unrelated to specific airplane data that are literally untapped. Folks that can turn basic API's into vastly complex entire systems, and they are blind to the inner goings on of DCS. I absolutely hang on every patch note, but I certainly can't afford the time to filediff a _G dump and the Updater logs and installations every Wednesday.

 

No one needs to break NDA's to mention specific items to target testing once these builds go public. We just need a few bones thrown their way and off they go. :)

[Danny_P]

+1 I'd agree that giving the community 'tasking' along with OB's could certainly help streamline/improve the reporting that goes on. For the community members who actually want to bug report (nothing against the ones that don't) it could help them give more in depth/concise feedback.

 

An 'overview' of api changes would be great too, like Pikes suggests, knowing where to look would be very helpful.

[McMicha]

I agree.

Also I would be happy if we could get some more information about which parts of the OB update were changed.

Otherwise only the same errors are reported, because we don't know if this function was touched with the update.

Personally I am interested in the functions for the export of the data, there are a lot of errors and inconsistencies.

[Shadow KT]

+1

[funkyfranky]

+1

[QuiGon]

+1

 

I totally agree. Currently there are often new addeitions or changes in a new patch that don't get mentioned in the changelog or anywhere else and if they don't work as expected I then wonder: "Is that how it should be? Is this feature still WIP and not yet complete? Have I discovered a bug?"

Often I assume a feature that is behaving in an odd way is just not finished and still being worked on, but maybe it actually is supposed to be finished and I have discovered a bug.

 

So yeah, it would be great to have some more info and direction what has been added/changed how and how it is supposed to function in its current build, so we can check if it actually function the way it should.

For example: The current implementation of the Hornet's INS is a big mystery to me as I don't know if it's already finished or still WIP and if it's still WIP, then what component is supposed to work already and how?

Edited February 5, 2020 by QuiGon

[S D]

Bumpity... +1

 

 

Definatly need more interaction/communication with those community members using "under the bonnet" features. Also just looking at this place.... Perhaps a "Technical Wishlist" forums, so we can seperate needed wishlist items relating to API's or other back of house features, instead of wading through every man and his dog requesting a new aircraft.

Edited February 11, 2020 by Shadow.D.

[JTFF - Raph]

+1