Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
No help = no progress = no new features = no public release.
#1
It has been very noticeable over the past few weeks that our testers are not actually testing all that much. Safe for MRMIdAS and one or two others, we're getting no feedback at all.

As such, I thought I should point out the following, very simple fact:
Without feedback, we cannot determine what works and what needs fixing.
Without knowing what works and what needs fixing, we cannot continue working on issues.
Without being able to work on issues, we cannot fix or finish them.
Without finished features or fixed bugs, there won't be a public release.

I realize that the recently reported crash could potentially make testing individual features difficult - but even that crash could've long been fixed if all testers worked on figuring out what causes it, instead of idly standing by saying "nope, can't test because it crashes".

I'm not really sure what else to say - take Operator=, for example. The code for that feature has been in Ares for over a month - and yet, the request remains marked unresolved. Why? Because there are complications with certain vehicle configurations, and nobody tested what works and what doesn't so far. So we can't actually patch it up to a fully working state.

And that's all not mentioning the 18 resolved, but unconfirmed issues in the tracker.

The fact of the matter is: Testers who don't test are of no use to us. There is no reason for you to have the test builds if you're not testing for us. So unless there is a significant change in the amount of feedback we're getting, we'll have no other choice but to change our testing team.
That's not a threat. That's just reality.
We need feedback to finish Ares. The current team doesn't provide feedback. What else are we supposed to do? Not finish Ares?

It's your choice, really. If you don't care, alright. If other things prevent you from testing, at least come forward and state "I won't be testing for another X weeks" so we can find a replacement in the meantime. But the way it is now is not acceptable, and will be corrected one way or another.

Choose whether you want to continue testing or not.
But if you choose to be a tester, test and report.
And not just that. Get more involved in general. Be on the tracker. Comment on issues. If there's a bug reported, get into the game and try to confirm it. Find the narrowest possible test case to make it easier to pinpoint and fix it. Post the results on the tracker. Even if the result is "I tested this the following way and can't confirm this issue" that's important to know. Knowledge is power. The more we know, the better we can work.

Contribute to development. Don't just sit on the sidelines and leech the test release every few weeks.

Also, consider joining chat for easier and quicker communication. No point in drawing out a series of tests that takes 30 minutes to conduct over 3 days just because each side is waiting for instructions or results.



And for all non-testers reading this: While I don't have the authority to add new testers to the team, I'm sure D is curious to hear who else would volunteer to do testing if the current team isn't interested anymore.

So if you want to be a tester, perk up. You'll be taken into consideration if personnel-changes are required.


P.S.: The same applies to the RockPatch→Ares converter, by the way. If you honestly think I'll magically finish that thing within an hour after Ares's public release, based purely on divine intuition, you are sorely mistaken.
I don't need that tool. I'll be fine without it. I have no reason to invest countless hours to wade through different versions of documentation, comparing features, reading through archived forum posts to figure out what actually worked, and so on. And even once I have all that data, it'll still take a while to implement everything and make sure it works, and then find someone to compile it under Windows for release.
Add to that that Christmas is coming up and very soon I'll be busy with other stuff than coding converters I don't need, and your chance of having a converter when the public release arrives grows slimmer and slimmer.

It's your choice. But as long as I don't see anyone actually cares, there is no reason for me to waste my time coding that thing.
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Reply
#2
Well. This is a shock.

I on one hand am fully appreciative of your work and definitely anticipate Ares' release. I comment on the features that I am interested in and see very many good things done.

On the other hand, I have not applied to tester as I thought I would face relative inactivity. I may not have time really to test more than a few sessions a week, mostly weekends. And despite me knowing full well how to access the latest build, I really don't have a use for it as unrelated to the project as I am. [I really don't think it would be nice putting my mod on it when a) it is not released, so may stall release of mod, and b) I shouldn't be having it]

However, the way you are describing it, the few times a week that I could do is still more than enough. Provided I be useful and make a detailed lists and all. So, there you go, I was originally just going to wait and watch, but now I'd like to apply to be tester. Tongue

Enough about me though, good job on this and keep up the good work.
Reply
#3
There are two solutions:

- Get new tester, there are many good modders out there that want to test
- Do VK style, release to public and the users will find all the bugs and D release revisions as people report(bugfix version)

A testing team is a bad idea imo, Ares it to large and require at least 100 people to find all bugs, thats why releasing a basic-tested version to public best option
Reply
#4
Quote:There are two solutions:

- Get new tester, there are many good modders out there that want to test
- Do VK style, release to public and the users will find all the bugs and D release revisions as people report(bugfix version)

A testing team is a bad idea imo, Ares it to large and require at least 100 people to find all bugs, thats why releasing a basic-tested version to public best option
Lost me at VK.


Sorry I haven't been around much, Ren. Started college in september and have been busy trying to overcome laziness and get some good A-levels... I am off on christmas holidays ATM, so might well dabble a bit in testing. Consider this my re-application to continue my role as tester.
Reply
#5
Computers seriously fucked, it almost always won't play Yuri's Revenge though I'm ggetting a new laptop for christmas so I should be able to resume testing then. Just to be clear, you want us to report when things work and don't or just don't work?
Reply
#6
We are most certainly not going to work VK style. Definitely not. Ares is supposed to be an extension of the possibilities a modder has, not a new source of bugs and IEs.
While software is never bug-free, modders need to be able to rely on Ares being relatively stable, so they can tell their users to download it in good conscience.
Remember, end-users often don't really have a concept of code ownership, software modularization, etc. If they use a mod, and the game crashes, as far as they're concerned, it's the modder's fault and the mod sucks. It doesn't matter if that IE was Ares-induced, the modder gets the blame - because it's his mod. And the people will not stop playing "mods with Ares", they will stop playing that particular mod, because "it crashes".

So the modder needs to be relatively sure that that's not gonna happen. He has to be able to trust that Ares is not going to cause problems, sabotage his work and enrage his users.

As such, the VK code cowboy approach is an absolute no-no.

@Black Shadow 750: You are supposed to report when things work as well - so we can be sure we're done with that and close the issue. Whenever something is marked as resolved, that means we think it's resolved. It stays listed for the very reason that we need confirmation that it's actually solved and there are no problems.
Again, Operator= is a good example. That was marked as resolved, because the code in general should've worked, and then reopened because problems surfaced. We just don't have enough data so far to resolve it completely.

And it's not just reporting stuff. It's also following up and re-checking. Just because a bug is already reported doesn't mean it's not important to know if others have it as well or not. Or whether it happens under different circumstances as well. For example, if a mod reports problems with IFVs, and you have the same problem with Hover Transports, that's important to know. It makes the difference between us looking into the game's IFV handling, and us looking into general Passenger= handling.
Again, knowledge is power - the more we know about a bug, the easier it is to identify the cause and come up with a solution.

A simple "I can confirm this happens for me as well" might seem superfluous to you, but to us, it rules out that the problem is due to a local issue on the reporter's computer. (It's not a coincidence "confirmed" is a valid bug status in the tracker.)

And mt., a few times a week would already be a big help. I'll poke the man with the capital D. Wink
Plus...as D said before, a public release isn't tooooo far away. We just can't finish the issues remaining if we don't know what's really done already and what remains, you know?
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Reply
#7
Where's the list of unconfirmed features/bugs, etc.? I want to continue with this, and continue being a tester.
EDIT: I have noticed that the fix for the "Only InfantryTypes can overpower buildings" problem continues to be shown in the manual as untested, even though I confirmed that it works.
EDIT2: And I am still experiencing seemingly random crashes, making it kind of hard to test anything.
"The present is theirs. The future, for which I really worked, is mine."
- Nikola Tesla

"My - y - my - your - my vision has permutated. My - y - my - your - my plans have followed a path unpredicted by the union of Nod and GDI. Your - my - our - our directives must be reassessed." - Kane/CABAL

[Image: 9853.png]
Reply
#8
It's the sole link I provided in my previous post. As for the seemingly random crashes, it seems like you didn't understand a major point I made - instead of complaining the crashes prevent you from testing, test where the crashes come from.
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Reply
#9
How do you read a crash dump?

I've tried testing what causes that crash, but every time I think I've figured out what causes it, it crashes randomly in a different situation to last time.
"The present is theirs. The future, for which I really worked, is mine."
- Nikola Tesla

"My - y - my - your - my vision has permutated. My - y - my - your - my plans have followed a path unpredicted by the union of Nod and GDI. Your - my - our - our directives must be reassessed." - Kane/CABAL

[Image: 9853.png]
Reply
#10
Just to update everyone, after a series of tests in chat (remember what I said?), it seems that the crashes appear when the user selects a production facility of any kind (which is consistent with a recent change in the codebase) - can anyone confirm this?
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Reply
#11
(Note that the crash they're talking about is not the same as the Midas Bug.)

Worth playing: 1 | 2 | 3
Reply
#12
Holy shit I've got a bug named after me!

on a serious note, it'd be good for other people to confirm "resolved" stuff, as D has seen, what works for one, may not work for another, so another person going "yeah that works" is welcomed.
[Image: MRMIdAS2k.jpg]
MRMIdAS: No longer allowed to criticise Westwood on PPM
Reply
#13
What is involved with testing? Do you have to have any specific computer knowledge or just RA2/Yuri game knowledge
Reply
#14
You need to have a fair knowledge of Yuri's Revenge modding and be aware of the current features and bugs in Ares.
"The present is theirs. The future, for which I really worked, is mine."
- Nikola Tesla

"My - y - my - your - my vision has permutated. My - y - my - your - my plans have followed a path unpredicted by the union of Nod and GDI. Your - my - our - our directives must be reassessed." - Kane/CABAL

[Image: 9853.png]
Reply
#15
Well, I have some knowledge of Yuri Modding. My recent issues with except errors came back to terrain I made. I have nothing but time on my hands so there is a possibility I could be a tester.
Reply




Users browsing this thread: 1 Guest(s)