[Topgun]

I had an idea. in a effort to avoid situations like this I think we should start a "experimental build testing team".
the team would be responsible for testing features in experimental builds. you could have some members of the team just test graphics stuff and some other member test animation code stuff ECT. that way the features can be tested to the fullest and minimize bugs when these features a committed to trunk.

Do experimental builds have a mantis? if they do the coder responsible for them should post a link in the build thread to it. if not, then I also propose a separate a board for experimental builds, that way the "recent builds" board will be exclusively for new trunk releases. this will help new users to differentiate between trunk and experimental builds. it will also keep the "recent builds" board from being cluttered.
what do you think?

[karajorma]

We've tried forming testing teams in the past and had very little success. I suspect one problem was that they expected the coders to provide all the direction when instead they should have been figuring out what possible problems there might be.

That said if you're willing to gather people together and do that I think it's a great idea.

[WMCoolmon]

We don't want new users testing builds, generally we want experienced ones. Most of the functionality provided by new features is in response to mod requests and longstanding interest in having a new feature available. A new user isn't going to crack open FRED, say, and whip up a complicated scene using the camera code, or start writing new ship types in the tables.

A formalized testing team would be nice, but last time I tried that, we had about 10 people signing up and only 2 people actually made an effort to check the forum.

I think it'd be more interesting if somebody wrote a test mission...I was just thinking the other day that a G-mod like mission could be pretty fun to test in. You could use show-subtitle and is-key-pressed 1-4 for menus, or record pressed keys using scripting and use script-eval-num to check 0-9. Menus and interface might be easier with scripting too.

I'll include a script with my next build that'll let you get the numeric value of the numrow, numpad, and function keys that you can use from FRED.

Code: [Select]

- when
-- =
--- script-eval-num "getNumPress()"
--- 8
-- send-training-message "8 pressed"

[Topgun]

this will help new users to differentiate between trunk and experimental builds.

I never said anything about them testing. and not just *new* users are the ones who get confused. I was confused about it until recently.
don't say I am a noob.

Do experimental builds have a mantis?

?

[Solatar]

If I'm not sure exactly how a feature works, or what it'll do, I generally just stay away from it.

I would think having the widest range of users testing features (on different hardware, etc.) would be beneficial. If it passes the 5 user test, and then is released to the public, it has to be tested again.

A simple 'new users, enter at your own risk' policy would do fine. I'd hate for new builds to be exclusive to only a certain user group.

[karajorma]

Do experimental builds have a mantis?

No. And they probably shouldn't either. Experimental builds are frequently compiled from the coders own codebase. He's the only person with a copy of the code so what good would Mantis be? Simply reporting it in the coders own thread should be enough as they should be fixing bugs in their own code as a priority.

[chief1983]

Garry's Mod for FS would be the bee's knees.  I like it.