Can we have it back? Everything is so disorganized now what with half of the EDT leaving and the new forums/mmf2 coming out- we need to get back into the old system and get some extensions released.
Printable View
Can we have it back? Everything is so disorganized now what with half of the EDT leaving and the new forums/mmf2 coming out- we need to get back into the old system and get some extensions released.
I think we may need to consider public testing of extensions.
Every tester we have lined up right now also has access to this forum.
I am also open to suggestions -- I didn't think the test tank did that good of a job but maybe it did?
No, it really didn't. What if we paid the testers $0.50 up to $1 for every bug they find? Surely then they would be finding tons of bugs :P.
"Pst... LIJI... Can you please insert some bug for me? I'm saving for something." :P
I actually like the test tank. :)
Personally I think the test tank did a good job, but never mind then.
They found bugs but they were horribly slow and inefficent... I know many of my extensions went a long time without feedback and even then a lot of the bugs didn't get caught.
The test tank was a good idea, but I agree it was slow and inefficient. It was also cyclic with active times and dead times.
I can't see paying beta-testers or even setting-up a system to compensate them somehow. In the past, we used to reward both devs and testers, (who were very active) with free upgrades or new versions of MMF.
Jeff and I both are not sure what we are going to do yet with extensions and testing, though we have mentioned some options for both in the past.
I am sorry that we are still procrastinating about this, but a time will come when some decisions are made. We have other, more pressing issues to attend to in the near future.
For now, continue as you choose to.
If I were a new "outsider" extension developer I would feel kinda unwelcome if all other extension developers had access to help in a hidden forum. All other communities are completely open about development about their extensions and everybody interested can peek in and see whats going on. I don't see why this shouldn't be the way Clickteam would do it. I understand some extensions could be made by contract for Clickteam so betas couldn't be posted in public space but then the EDT here is good I guess (users signing a contract not to leak info about it and all that stuff)
I don't think it's a problem if people try to use experimental and unfinished extensions, in the end it's their own bad choice not something we should try to prevent. We can only encourage them to wait for the final releases before they use them for any serious work.
I can still see benefits to having this area private. Preventing pirates from gaining extensions, and protecting devs from being bugged by eager clickers are two strong reasons.
Public betas are ok, but we need better ways to control them that minimize confusion.
I didn't say the private forum should go away, just that I felt that a "Public beta testing forum" would be a good idea.
With a category name like that "Public extension beta testing" or similar then I can't imagine people getting confused. If all extension developers put a popup at the time the extension is dropped i the frame (very easy to do) then I say that would be enough. (I don't like those runtime popups, they discourage people from testing the object because it's annoying)
The popup, (while annoying) is supposed to exhibit at runtime so that anything created with the extension will alert users of an executable. So, maybe I don't understand you there, Andos ;)
What would be a good solution, but would probably require modification of MMF2 itself, is to be able to make a beta extension un-compilable. In other words, you could NOT generate an exe or even a Vitalize app with the unreleased version of the extension. Is this, in theory, technically possible if MMF2 were modified?
We can keep this area for now, but I would like to suggest an interesting idea, (something that Joewski, who has really taken on the Click WIKI, might be game for) and that is for the developers here to spearhead a real movement towards a development environment for MMF2 extensions and movements. They would be independent extensions and testing could be done in the same location. This idea could be strongly promoted on the forums here, once it is in place.
From there, the politics are up to the community of developers who work together to create and publish new extensions, (and you know that CT would support the outcome as far as news on the site and the forum goes.) I mean, you might go open-source, or you might just want to encourage the creation of as many useful and powerful extensions, movements, etc., as is possible -- and keep them free and easily avialable.
I would like to interject here that one request I would have, (and I think everyone here, by now, knows the reasons for it) is that altruistic developers who are not doing open-source, could be encouraged to entrust up-to-date copies of source code for safe-keeping and potential updating for future versions, at the very least. Maybe the community could create various levels of what the code could be used in the future and under what conditions?
As you all know, myself and CT, have certain extensions, or even updates on stock ones, that we want or really need to have done for specific, practical reasons. Those may be privately contracted and testing would be done in whatever ways we find most practical. Perhaps we can arrange to at least privately notify developers when they are duplicating an idea we already have in production? I am not sure, but that may be workable and pragmatic to avoid redundant work.
You can make an extension uncompilable quite easily... I think vortex knows how.
As Turbo once wrote:Quote:
Originally Posted by Jam
Code:LPCSTR* WINAPI DLLExport GetDependencies(mv _far *mV, LPEDATA edPtr)
{
return NULL;
}
Yeah, that's an SDK bug that will make the exe goes 0 bytes.
The testing group was a good idea, but obviously did not work as well as people hoped.
A developer would look to the group to be always there and active, while people in the group are all of different interests and not necessarily able to dedicate their time 24/7 to testing every extension dropped in over time.
I think another approach that could be taken, based upon a more open beta testing as being discussed above is for an extension developer to request people put their names forward if they would be interested in participating in testing your object. You then have a list of people, and they know what they are being asked to do and when they are being asked to do it. You will still ahve people drop out and some people more active than others, but you can manage the relationships and everyone knows where they stand.
It might not be a bad idea to split the public extension forum into two -
1) The current extension forum for released extensions, general extension chat and support.
2) A new "Public beta" extension forum, for developers to have a means of managing their testing. This has benefits that users will not be confused between what are beta testing and what are released extensions, and developers & testers alike will be able to easily find all the threads related to their activities.
Although anoying, the pop up dialog is very important and I believe should remain because we need to ensure beta extensions do not get mixed in with released extensions. For one support would be a nightmare because beta extensions can change radically over their lifetime and I'm sure no one wants to have to try to manage different builds of extensions.
I also think that it is important to keep some private forums so that extension developers can work closely with each other and with Clickteam. The thing with a private forum though is to make sure that new developers who appear on the scene can have an opportunity to join - especially if it looks like they are here for the long term. I think you've got this working pretty well so far.
Actually I think you can just put the popup in the runtime version of the extension. MMF2 seems to use the edittime extension at runtime when runned from MMF2 and only use the runtime extension when saved as an .exe
Also if you use that SDK bug to make exe files 0 bytes in size, the users of the extension would probably try to copy the edittime extension over in the runtime folder but then you will just get the annoying popup there and maybe the extension could force the game/app to close after that.
Novabrain:
I'm just saying that those popups you get every single time you run a file using a beta-extension really annoys the tester. I can remember several times I've stopped testing an extension because of it. If the popup only is displayed when the user tries to use them in exes and other places then I don't see a problem.
You use the SDK bug in the edittime version as well.
Popups are useless!
I can't make it clear enough! It takes 2 minutes to remove the popup completely, and I can prove it too.
If people really want to go so far just to use an unfinished extension I wouldn't care much :) It's just a waste of energy for them and they will just run into problems later. I don't see why it should be "illegal" to use them before they are done, the popups are just there to encourage them to wait.
On public versus private testing:
I am all for public testing of extensions but I worry the extension developers would get bothered to death.
the one nice thing about popups is at least a user can see the extension is not yet completed and they use it at their own risk.
If they hack out the popup and then later complain about a more recent version of the object being incompatible thats a risk they take.
I agree with Andos its their time and energy to waste.
It isn't a waste of energy because when you know how you can do it in (literally) 30 seconds.
An idea I liked that was going to be done, was the registered user program. Only registered users of the products would be able to participate in the public beta testing, however with this particular forum, I am not sure how possible that is..
Good idea- on the forums for Neverwinter Nights (http://nwn.bioware.com) you enter your CD key when you sign up. This does two good things- stores your CD key for later recovery if you lose the CD case or whatever, and it also gives you access to bonus features/forums.
My waste of energy is when....
A person decides to hack out the pop up and use the extension
Then later the developer changes things and fixes problems and the new version is completely incompatable with the previous beta copies.
The user might have to redo all his work if he/she need the new features bug fixes.
Hmm, I'm in two camps regarding this issue.Quote:
Originally Posted by AndyH
Pro's
* Extension gets out and people start using, in professional products might make MMF2 look buggy and bad.
Con's
* Using the testing area for private testing, as has previously occurred and never to see any sort of release.
* Previous cases of usable extension source code lost.
* May discourage more wide spreed testing.
I think Alpha's should have popup's but beta's and Release candidates shouldn't, as there interface should be stable.
I agree with Andos here. If there were no pop-ups when run from MMF, I'd use more beta extensions in my projects, testing them as I go.Quote:
Originally Posted by Andos
Usually I don't have the time to test an extension just for the sake of it. But when I can actually use the extension for something, I can do both at once. Plus it's much more likely that I discover rare cases that might be buggy. But it's impossible to work on something with 5 popups showing up every time you run it.
I really don't see much use in popups other than to annoy the hell out of everyone who wants to test/use them. If it really needs to be displayed that a beta extension is being used, why not display a string at the upper left of the application that says "BLABLA extension is still beta", which disappears after 30 seconds.
But people aren't using them, they are testing them. And if you go for a public beta, you can choose to limit to a number of people or not, but hopefully the people who are testing are doing so because they want the extension.
It can also help to keep you guys motivated and finish the extensions if more people are testing and supporting you. Yes, you will be exposed to being bugged by people, but I think everyone is big enough to handle it, and it beats getting little to no feedback at all does it not?
But what I am suggesting is that the extension developer can control their testing, how they do the pop ups and how they work and pick their testers. I just wonder if keeping it all closed for so long is counter productive? You may not want to release something you consider in an alpha state, so again it would be up to you when you start asking for testers.
Back on pop ups, the reason they are important is that you release ver 0.9 and people download it. They love it and start testing. Some love it so much they start using it for their games. Others might get the extension without realising the state it is in. You then make a big change - fix a serious bug or add a different way of doing something, or new requested functionality and release 0.91. More people download it, but maybe not everyone. You finally release version 1.0 and they you've got to support all the versions floating about out there. Why does my game crash, why can't I load my game in with the new version of the extension, etc...
That's the danger as I see it.
If you could repress the dialog in edit time but only display it at run time, that would be ideal. If maybe you could add a check box for the edit time version so the user can tick to not see it again (in that version) then that could be good too. But being made aware of the extensions beta state could be beneficial in the long term. If the user wants to hack it out, that's their problem to manage.
Of course you could look at other options such as putting an expiry date in, and then put a pop up to let the developer know where to get the new version.
This is a good discussion and I appreciate the input.
There are many solutions and new ideas to explore.
In addition to whats already been discussed, I can see that we need a better way of managing extensions. I've been thinking about writing an application for a while to tackle the issue.
The very problem of extensions not being updated is a issue.
I was thinking of a program that checks both the runtime and extension directory for the following.
* Downloads a list of extensions from a web site.
* That list is compared to the extensions in the runtime and extension directories.
The comparision, checks for version number, size, hash, and if the file exists, along with the filename and language version.
Also any new files are reported.
If a new version exists then that is made known to the user.
There may be a link to the download page or say even the Wiki or forum or all.
If there os a new file that doesn't exist, then the user has a dialog box pop up, which asks for a description of the file and purpose. Typically this could be a alpha/beta/or private extension. If it is private the user nominates that it is private and a message is sent to the list controller, who adds the information to the list. It won't appear in other peoples lists as a missing extension. But if it is in that persons list then a information line will appear. There could be an option to make it public knowledge but not appear in missing lists.
That way clashes in filenames could be detected early.
Version control would be much better, and alpha/beta extensions better maintained.
I think also there should be more categories in the insert objects dialog box of MMF2. One should be vitalized objects, and the second should be Beta Objects.