Future Organization?

Hey <img src="/center/images/graemlins/smile.gif" alt="" />. I have started this thread to start a discussion about the current level of planning involved when it comes to creating a bonus pack.

It seems that currently the bonus packs come out "whenever" without any sort of planned or expected dates. As a developer I find this frustrating as if a bonus pack isn't ready when I am, I will just release my extension myself.

Now I have several ideas that I would like to include in Platinum Bonus Packs, but I need motivation besides just holding the ideas....

I feel as if a better level of organization is required for this program. I would like to have tentative completion dates and incentives to create, better testing, and more organization when it comes to patches and feature updates.

I don't see why Clickteam can't share the bonus pack technology so that we can create independant packs that are hosted and approved by clickteam. For example I could release a pack of my OWN extensions, have the source registered with clickteam, but I would have more control over how, when, and what the pack contains.

There is nothing wrong with a Vortex 2 bonus pack <img src="/center/images/graemlins/smile.gif" alt="" />
If you have some ready to go then thats all that is needed, no use waiting till enough is done from other people.

I could make a pack containing updates to Lua, EasyXML, Platform Swing and including Web Browser, Audiere, EasyScrollbar, Frame Size, and perhaps even Sprite Array.

That would be an awesome pack <img src="/center/images/graemlins/smile.gif" alt="" /> and more then enough.

I thought about making a LIJI fun pack with my (coming soon) mini projects <img src="/center/images/graemlins/smile.gif" alt="" />
Colorizer (Change the colors (not only by HSL <img src="/center/images/graemlins/wink.gif" alt="" />) of a selected area)
3D Actives (Turn normal actives to 3D (flat) sprites)
Get Movement (Get the speed, angle etc of a chose active)
Easy Detector (Checks collisions in offsets without extra objects)
and maybe
Crasher (Pretty usless but crashes your program by a division by zero, might be useful if you need the program to crash and make the user think it's some random one :P)

I like the idea of extension developers making enough objects for a bonus pack creation <img src="/center/images/graemlins/cool.gif" alt="" />

Perhaps you guys could consider themed ones as well? You know "Adventure", "Isometric", "Board Games", "RTS"...etc etc.

So there would be a set of objects that do certain aspects of a game, that would be great..anyway just an idea.

Jason

Yes one of the problems I feel the bonus pack model has currently is managing updates. Sure we can send updates to Yves but who knows when they will make it into the update and then who knows who will actually download it :P.

I think that both one-dev and themed packs are an interesting idea. A minimum of 4-6 good extensions would be good and we could personalize it. Instead of numbers for the PBP's we could use names to distinquish them. Something worth considering.

As for updates, perhaps there is a way to manage them? I do suggest a time period that allows reports to accrue, unless the fix is critical. So far, we have had less problems with the BP extensions than I expected and it takes a while, sometimes, for deep bugs to be discovered by a user. The change to MMF2, (compatibility) seems to have generated more problems than in the past, it seems.

Couldn't we create a private, Dev forum for info on PBP updates so that Yves can monitor them, communicate, and comment? An example would be, he could keep an eye on the number of updates and decide when to publish the fixes. That way, both Yves and Devs know what's going on and when. A Dev might find out that a pubilcation date is coming and get a patch in beforehand.

I am hoping that we get more projects going here, (Alpha/Beta) so that we can start working on a potential pilot for some form of public testing. I would like to get that going by the end of the month, that is, if everyone is with me on it. If it does not work out, we can go back to private invitation-only testing.

I personally would be willing to develop a number of new extensions for a chance to help get Jamagic back into a supported product <img src="/center/images/graemlins/wink.gif" alt="" />.

Vortex2, it would be great if in co-operation with Clickteam you could make an object that could host Jamagic sessions in MMF2 and vise vera. I think by intergrating it would be great.

LIJI
Colorizer (Change the colors (not only by HSL ) of a selected area) - Nice idea
3D Actives (Turn normal actives to 3D (flat) sprites) - Many would like this.
Get Movement (Get the speed, angle etc of a chose active) - Useful.
Easy Detector (Checks collisions in offsets without extra objects) - Useful for gamers.
and maybe

Crasher (Pretty usless but crashes your program by a division by zero, might be useful if you need the program to crash and make the user think it's some random one :P) - Yes and its not useless, it could be used to discourage piracy if applied correctly.

i.e. Make your application with a two part key. The first part of the key is released with a keygen to some warez sites. Your application should work for 30days say. Now if the second part of the key which is tested later fails your key test use the random crash object randomly through the application. That way the keygen looks good and no hacker can be bothered to crack your app. Naturally you offer a patch on your website for subscription customers, and again you apply the same process.

The only comment &amp; suggestions would be if you could have different types of crashes. ie. application crash, system lockup, mouse lockout, keyboard lockout, jam ports, system slowdown by x%, memory leaks, blue screen of death, system resets, etc.

You could also consider a method of making custom message like microsoft does. i.e. Your application has crashed to help us develop a better products you are invited to send a core dump. read the contents of the message, send message, don't send.

So its not as useless idea IMHO as you think LIJI.

I thought about publishing it for April's fool :P
Mmm... thanks for the comment! <img src="/center/images/graemlins/laugh.gif" alt="" />
BSoD are pretty evil, I wouldn't like to make an extension that do that! :P (In the last 10 minutes I got 2 BSoDs... And I'm using XP)

system lockup, mouse lockout, keyboard lockout, jam ports, system slowdown by x%, memory leaks
What are those?

I'm against single developer packs but I am for themed packs.

However, I mostly post so say that it would be quite silly to crash the program by a divide by zero. Why not use the function 'FatalAppExit', as that is what it is for.

Hey, mind telling us why you are against them? <img src="/center/images/graemlins/wink.gif" alt="" />.

I just like the variety that the bonus packs have given. Also I think only larger extensions should be in a pack, and one developer cannot come up with many large extensions at the same time (you may be an exception there Vortex)

Valid points. The problem with multideveloper packs is settling on a timeline that can get the projects released and yet still be inclusive of a variety of extensions. It is easier for one developer to come up with a time frame rather then multiple developers try to agree :P.

I think this is a good and timely discussion. Especially for me where I have 2 extensions I am thinking about what to do with right now. I will just list my thoughts in no particular order:

- Individual developer packs should be encouraged because it builds a stronger community and new business models. As pointed out, developers may put in more time etc and future support if they have chance of getting paid. Also it encourages investments in really powerful objects.

- If people don't want to do that (like me - right now at least), I would want to make them available for CT bonus packs like before. Then if I fade out a year from now or get hit by a bus CT can keep the extension alive by having source code etc.

- Once an extension is in a CT bonus pack, it should stay there. So I would not be in favor of vortex releasing a 'fixed' or slightly enhanced LUA object in his own pack if he already released a version in a CT pack. MAYBE he could provide a much-enhanced PRO version, if a standard version was previously available in CT bonus pack. But the CT packs should not contain trial objects in my opinion.

- I think CT really needs to open up a bonus pack BETA area with a discussion thread and a place to download extensions proposed for inclusion in the next CT bonus pack. This is open to all not just EDT. This allows developers to finish an extension and 'get it out there' sooner while providing an expanded testing program like Nova wants. Once enough extensions are collected with good feedback and stable, they are formalized in a new bonus pack and removed from the beta area. Maybe the EDT could review them prior to putting in the beta area.

- Themed packs are interesting, but it would require good focus of the EDT to avoid long delays while extensions 'collect' that fit the same theme. If there was a big new initiative that many EDT members were all building related extensions maybe it would work - like an 'education' initiative or 3D or something. I think stronger incentive would be needed to pull this off.

I really wish I could post Super Function to a public beta or bonus pack staging area now, I am really struggling because I don't want to wait until end of year. I think with Power Function end of life there is a big hole for people working with MMF2.

Well, my thoughts anyway. If we had a public bonus pack download/test area I would post there tomorrow and be happy.

JSJ

I think that it doesn't matter if the extensions and add ons are in bonus packs or whatever.

I have been thinking about an application that does version checking of all MMF extensions vs an online file.

Everytime somebody learns of a new extension or add-on etc it goes into the knowledge base.
The program will compare what you have with whats on the database.
If you have something nobody else has or the database is not up to date you will be encouraged to make an entry.

Thats the idea I have.

I also think that bonus packs in beta should be opened up for the public. I don't think we get enough testing for our extensions even though those who are active testers does a great job. It is just easier to find bugs when they are more commonly used for many different things.

I also think that each extension should have a chekbox in the installer so each extension is optional. It's like installing Windows with alot of "forced" software like Windows messenger and internet explorer though some people don't want them.

[]I also think that bonus packs in beta should be opened up for the public. I don't think we get enough testing for our extensions even though those who are active testers does a great job. It is just easier to find bugs when they are more commonly used for many different things.[/]
Yes, I agree, but the idea of Beta testing is to avoid some basic problems before they become public. Testing is very time consuming, that requires test applications to be made so testers can test on various plateforms.


[]
I also think that each extension should have a chekbox in the installer so each extension is optional. It's like installing Windows with alot of "forced" software like Windows messenger and internet explorer though some people don't want them. [/]
Thats not a bad idea. Personally I find it easier to install all the extensions cos, I end up loading applications from the forum, and you never know what people have used.

[]I don't see why Clickteam can't share the bonus pack technology so that we can create independant packs that are hosted and approved by clickteam.[/]

I could release a special version of Install Creator Pro just for that. But it needs a little work. I'll do it after Vitalize 4.

Yves.

Now that is a good idea <img src="/center/images/graemlins/wink.gif" alt="" />.

I think the key difference with BP extensions vs others is that source code is logged with CT and there is a standard packaging mechanism with some implied promise of future longevity. Just looking at the move MMF2 and how many extensions had 'lost' source code etc, I think the distinction between a BP extension and general public one is important. I do not think general independent extensions can always be treated the same as they do not have the same implied 'promises' for the future. Thus I am saying I do not think BP extensions and other independent extensions should look the same to users. To the extent they use similiar tools, they need to have clear and distinct categorizations.

I wouldn't mind registering my source with Clickteam. Perhaps there could be a "Clickteam Approved" seal that we could use?

I was thinking a dev could release a pack using the BP tech, register the source with CT, but manage it himself. This would take work off of Yves and allow us to get stuff out at a much quicker rate. These extensions could also be hosted on the Clickteam site... It is basically the same ideals as a bonus pack, just decentralized. This approach would give Yves more time to work on things like Vitalize and put the "bonus packs" in the hands of the devs.

I like that idea. Give control to the third party developers, but allow the application to continue to develop in the future with out the risk of loosing source code and extensions over time.

If Clickteam has the source, shouldn't part of the quality be that the extension that is certified will be supported into the future? i.e. If the extension developer leaves Clickteam has premission to keep the developers legacy alive in all future revisions of the Extension.

Yes, that would be the whole purpose behind the Approved label. I would like if every possible effort was made to contact such developer but if that developer disappears off of the face of the planet, then CT would be able to convert or do whatever.

I like the ideas that come popping out here. <img src="/center/images/graemlins/smile.gif" alt="" /> And personal/creator's bonus packs seem great too. <img src="/center/images/graemlins/smile.gif" alt="" />