"Physical" Multicrew broken for anyone else?

[StefanOS]

You mention AX CZ - of cause MP is better for them - but MP works most of the time (with some hickups), but noone in AXI would try that in multicrew and it would not make sense either because its better to have 2 cmdrs in 2 ships as 2 cmdrs in 1 ship.
I agree that the ISSUE TRACKER, the CONFIRMATION system and mostly the lack of feedback on issues from FD is a HUGE problem. As this remains unchanged since introduction - I guess there is just not enough man power aloceted to make this system work - even in its current form. The CONFIRMATION system is a HUGE discouragement for me to put effort in reporting issues - if I do I have to trigger friends to check and confirm the issue to get 10 confirmations - because otherwise its just wasted time.

 

[Brannor]

You mention AX CZ - of cause MP is better for them - but MP works most of the time (with some hickups), but noone in AXI would try that in multicrew and it would not make sense either because its better to have 2 cmdrs in 2 ships as 2 cmdrs in 1 ship.
I agree that the ISSUE TRACKER, the CONFIRMATION system and mostly the lack of feedback on issues from FD is a HUGE problem. As this remains unchanged since introduction - I guess there is just not enough man power aloceted to make this system work - even in its current form. The CONFIRMATION system is a HUGE discouragement for me to put effort in reporting issues - if I do I have to trigger friends to check and confirm the issue to get 10 confirmations - because otherwise its just wasted time.

Agreed that you shouldn't have to socially engineer your own QA team to confirm incidents of an issue in order to get the product owner to take action on it.

It is discouraging to properly report a feature breaking bug, then watch it sit there because while 20 other people reported it - they all did it as individuals on separate tickets, thus it gets ignored.

I get what they are trying to achieve (lowering support costs while increasing community involvement), but it creates this weird survivor bias where focus only gets placed on items that matter to specific clusters of users.

The theory is that large groups of organized users will identify and confirm critical issues. The result is that they identify and confirm issues critical to them, which isn't necessarily what is impacting the majority of users or the product features that would expand your player base, but are currently ignored by players due to bugs.

 

[StefanOS]

Agreed that you shouldn't have to socially engineer your own QA team to confirm incidents of an issue in order to get the product owner to take action on it.

It is discouraging to properly report a feature breaking bug, then watch it sit there because while 20 other people reported it - they all did it as individuals on separate tickets, thus it gets ignored.

I get what they are trying to achieve (lowering support costs while increasing community involvement), but it creates this weird survivor bias where focus only gets placed on items that matter to specific clusters of users.

The theory is that large groups of organized users will identify and confirm critical issues. The result is that they identify and confirm issues critical to them, which isn't necessarily what is impacting the majority of users or the product features that would expand your player base, but are currently ignored by players due to bugs.

We all understand the idea behind the confimation/acknowledgement system - but it has some really serious drawbacks, as you mention. The biggest problem in the issue system is that even with the confirmed issues, the acknowledged rate from FD is very low.
I do acknowledge that ED is an extrem complex and huge game - and therefore the amount of bugs is also huge. To get rid of them would need a huge group of programmers working on it constantly. It seems ED is not offering so much profit that these investment can be done.
FD knows the problems existing in MC, its been written and reported many many times. Its doesnt look that it will fixed. And I doubt that fixing it would bring people back to ED. on the other hand just changing the respawn logic in MC should not be a very big task for a programmer - and would make this feature at least viable.

 

[Daniel Cloudsifter]

You mention AX CZ - of cause MP is better for them - but MP works most of the time (with some hickups), but noone in AXI would try that in multicrew and it would not make sense either because its better to have 2 cmdrs in 2 ships as 2 cmdrs in 1 ship.
I agree that the ISSUE TRACKER, the CONFIRMATION system and mostly the lack of feedback on issues from FD is a HUGE problem. As this remains unchanged since introduction - I guess there is just not enough man power aloceted to make this system work - even in its current form. The CONFIRMATION system is a HUGE discouragement for me to put effort in reporting issues - if I do I have to trigger friends to check and confirm the issue to get 10 confirmations - because otherwise its just wasted time.

I understand your point, but there are still a few caveats in regards to AX combat and multiplayer:

1. You're assuming all commanders are fully equipped and ready to risk AX combat. I'm wanting to bring friends with me who don't often play (but might get sucked back in if they had fun) and would have fun using the SLFs to assist me in light AX combat.
2. AX Restoration missions are, by they're very definition, AX combat. Again, I have friends that would love to take part in this with me, but they would need to hitch a ride (physical multi-crew) on my ship, as they don't have the ships to endure/evade AX encounters (especially with the new Glaives in the mix). Worse, we can't use the MP favorable SRV - the Scorpion - as it aggroes Thargoid ships while the Scarab doesn't.
3. Even if my friends came in their own ships for AX combat, there is still the problem with AI SLF pilots causing lag issues. This would hinder our performance.

While multiplayer is more stable than it used to be, I still don't fully trust it and it is a major barrier to get any new (or inexperienced, returning) player involved.

On the whole, though, I think we are more in agreement than in disagreement.

As for the Issue Tracker - that thing is an abomination! If I had to guess, I'd say the whole confirmation workflow was an attempt to eliminate duplicate tickets. I don't know. But they need to revert it to a system like they used previously - you reported an issue and it stayed in the system until it was resolved or marked as closed (after review). Heck, they don't even give feedback on the issues they keep open any more. Again, I go back to the Rotational Correction/thruster reduction bug - 1.5 years to fix. The community identified the bug, identified the setting that caused it, and offered the potential work around! Their response: nothing on the various tickets (more than one) that stayed open (or the ones they closed due to lack of confirmation), a brief mention that it was on ongoing issue with the Update 13 patch notes (bug introduced in Update 9), no mention in Update 14 or 15 patch notes, and then suddenly fixed in 15.02. The amount of player testing and documentation vs. their communication and speed on fixing the issue - the ratio is mind boggling.

I'm hoping someone has actually filed a bug issue on the Scorpion SRV aggroing Thargoid ships like it were a parked ship (as opposed to Scarab being ignored), but I'm so disgusted with the Issue tracker I won't bother to report the issue. Argh! It makes me so mad (both the bug and the Issue Tracker)!

 

[Brannor]

FD knows the problems existing in MC, its been written and reported many many times. Its doesnt look that it will fixed. And I doubt that fixing it would bring people back to ED. on the other hand just changing the respawn logic in MC should not be a very big task for a programmer - and would make this feature at least viable.

I agree that fixing team respawn is the first required step to make onboard multicrew usable enough to get players to consider using it regularly.