Download: iArcade System 1.0.0 Final

[Amy T]

indeed I know what you mean. I am a member of so many sites I have trouble keeping track of them all.
The number of sites has only gone down do to either that site having a policy to delete members after so long or the site gets closed.

[Mat Barrie]

Oooh that went straight over my head lol, what is that. [img]

' alt='' class='ipsImage' >[/img] Its just that every board you go to you have to register, and after a about 20 you just get cheesed off with all the registering and or signing in. Thanks [img]

' alt='' class='ipsImage' >[/img]

Facebook Connect means that if you have Facebook, you can just click a button and your Facebook login then works on the board, without having to login to it.

[Mr. Legacy]

Ok i figured out the Db issue the only problem i am having now is the games arent playing and i have downloaded them from ipbarcade and the games i have installed are V2 games. Any suggestions? I can toss you my admin and ftp info if neccessary in PM.

[Amy T]

Facebook Connect means that if you have Facebook, you can just click a button and your Facebook login then works on the board, without having to login to it.

would be awesome of facebook connect was active on the site.

[Andy Rixon]

Ok i figured out the Db issue the only problem i am having now is the games arent playing and i have downloaded them from ipbarcade and the games i have installed are V2 games. Any suggestions? I can toss you my admin and ftp info if neccessary in PM.

Check the path settings for iArcade as it sounds like the paths are incorrect.

[StangVert]

I'd been following this project closely for quite a while, but I had a huge deadline that took all my attention for the past few weeks. I apologize if this has been answered in the many pages since I was "all caught up".

I'm still running v2.3.6 on a certain site that may want an arcade. Right now, I'd be installing it on a v3.0.5 test board (on the same domain), but I'll be upgrading the "live" board in a month or so.

I don't want to mess up your accounting. Do I provide the URL of the test site that will be using iArcade for now? Do you want the live site registered separately when I upgrade? Or should I register just the live site, to cover both?

Maybe I was just too tired to think (an excellent possibility), but that was the "stopper" that kept me from installing and registering your component when you first announced the registration.

[Collin1000]

I'd been following this project closely for quite a while, but I had a huge deadline that took all my attention for the past few weeks. I apologize if this has been answered in the many pages since I was "all caught up".

I'm still running v2.3.6 on a certain site that may want an arcade. Right now, I'd be installing it on a v3.0.5 test board (on the same domain), but I'll be upgrading the "live" board in a month or so.

I don't want to mess up your accounting. Do I provide the URL of the test site that will be using iArcade for now? Do you want the live site registered separately when I upgrade? Or should I register just the live site, to cover both?

Maybe I was just too tired to think (an excellent possibility), but that was the "stopper" that kept me from installing and registering your component when you first announced the registration.

In RC1 (and all the RC versions) the registration system is tied key-only. This means that, in theory, 1 key can be used on an infinate number of domains. This was done to ease-in the optional registration. In the Final release, the ACP will show an error (as it does with an invalid key) that the key being used is for the wrong domain. However, at this time, we are using registration keys simply to gauge installed users. Nothing else is used. (Although, when a new version comes out, it will alert you to an upgrade)

Based on the data I have collected, 4 out of every 5 users who download iArcade will install it onto a board, and 3 of those 4 will register the install.

Registration is a totally optional process that allows us to better support our users and understand what the needs and demands are. :)


Thank you for choosing to register your arcade, if you have any further questions, I would be more than happy to answer.

[Ryan11433]

Just to let Andy and Collin know, I registered a account on your forums.

[Andy Rixon]

Thanks for registering :D

[Arianna]

I registered as Arianne, slightly different name spelling.

[Collin1000]

Now is an important milestore in iArcade.
With the upcoming release of IPB 3.1, I want to move challenges, reported games, etc away from the PM system, and use notifications instead.
I would also like to do this for "Your score was beaten!" type situations.

However, doing this would require that we drop support for IPB 3.0 branch.

What do you guys think? Should we continue progress on the 3.0 branch, release a final, and then move on to iArcade 1.1 for support with IPB 3.1's new features?

[AngelFire]

What do you guys think? Should we continue progress on the 3.0 branch, release a final, and then move on to iArcade 1.1 for support with IPB 3.1's new features?

my vote goes with v1 with 3.0 and then v1.1 for 3.1 as we dont know how long 3.1 will be till fully stable and i think no point in holding back a nice arcade

[Peter F.]

my vote goes with v1 with 3.0 and then v1.1 for 3.1 as we dont know how long 3.1 will be till fully stable and i think no point in holding back a nice arcade

That'd be my preference here, and is what I'm planning on doing for the Social Groups mod I'm developing. However it is possible to check what version number they are running and tell it to act accordingly:

// If the forums are 3.0.5 do this...

if(IPSLib::appIsInstalled('forums') && IPSLib::fetchVersionNumber('forums')==30012) {


// If they are 3.1.x or greater do this...

} elseif(IPSLib::appIsInstalled('forums') && IPSLib::fetchVersionNumber('forums')>30012) {


// otherwise give out to the user for trying to use on an unsupported version

} else {

   $this->registry->output->sendError('langstringidentifier');

}

This means that one can support *both* versions without needing to compile two versions of the mod for download.

[Collin1000]

That'd be my preference here, and is what I'm planning on doing for the Social Groups mod I'm developing. However it is possible to check what version number they are running and tell it to act accordingly:

// If the forums are 3.0.5 do this...

if(IPSLib::appIsInstalled('forums') && IPSLib::fetchVersionNumber('forums')==30012) {


// If they are 3.1.x or greater do this...

} elseif(IPSLib::appIsInstalled('forums') && IPSLib::fetchVersionNumber('forums')>30012) {


// otherwise give out to the user for trying to use on an unsupported version

} else {

   $this->registry->output->sendError('langstringidentifier');

}

This means that one can support *both* versions without needing to compile two versions of the mod for download.

The issue is the features I would like to build into it. I also dont want to delay iArcade for the sake of 3.1 coming out.

[Peter F.]

The issue is the features I would like to build into it. I also dont want to delay iArcade for the sake of 3.1 coming out.

So build it for 3.0, then when 3.1 beta comes out add in temporary support in a version increment for both versions at once, then when 3.1 is stable increment again and remove the dual support.

[Volstate]

my vote goes with v1 with 3.0 and then v1.1 for 3.1 as we dont know how long 3.1 will be till fully stable and i think no point in holding back a nice arcade

I second this. I've been waiting a long time for this arcade and am eagerly awaiting for it to be finished! I may hold off upgrading to 3.1.

[Ryan11433]

So build it for 3.0, then when 3.1 beta comes out add in temporary support in a version increment for both versions at once, then when 3.1 is stable increment again and remove the dual support.

I agree with that. ;) Andy and Collin I have a question. What do you think?

[Collin1000]

I agree with that. ;) Andy and Collin I have a question. What do you think?

Im intentionally not posting what plan I like best as to not sway your opinion.
;)

[Amy T]

So build it for 3.0, then when 3.1 beta comes out add in temporary support in a version increment for both versions at once, then when 3.1 is stable increment again and remove the dual support.

I third this.

[Collin1000]

Well, one thing has become clear: Not everyone can be happy! The votes are tied, 3/3. 3 votes to continue development as-is, release a 3.0 branch, and then move on to a 3.1 version. 3 votes to build in "backwards compatibility" for the 3.0 branch, but start building into 3.1 when it comes out.


Some points to clear up here:

* I will not begin ANY work with new 3.1 features until 3.1 reaches a very stable beta version. This could be months or weeks away.
* I am not a fan of having to support one version of my software with two versions of IPB.
* I think having to build in backwards features may stifle progression of new features, like the challenges system, and tornaments. (I plan on using notifications for this, it solves alot of problems we are having right now)

Now that most of you have voiced yourself, I'll post my side of things: I prefer to continue working on iArcade's current branch, under IPB 3.0 - Making sure it *works* on IPB 3.1, but not building in new features. Once iArcade reaches a stable point, I will shutter new development for it, and move into iArcade 1.1, for IPB 3.1, without any backwards compatibility.

Now that my "plan" is laid out, so to speak - what do you guys think?

[Amy T]

Sounds good to me.

[Ryan11433]

Well, one thing has become clear: Not everyone can be happy! The votes are tied, 3/3. 3 votes to continue development as-is, release a 3.0 branch, and then move on to a 3.1 version. 3 votes to build in "backwards compatibility" for the 3.0 branch, but start building into 3.1 when it comes out.

Some points to clear up here:

* I will not begin ANY work with new 3.1 features until 3.1 reaches a very stable beta version. This could be months or weeks away.

* I am not a fan of having to support one version of my software with two versions of IPB.

* I think having to build in backwards features may stifle progression of new features, like the challenges system, and tornaments. (I plan on using notifications for this, it solves alot of problems we are having right now)

Now that most of you have voiced yourself, I'll post my side of things: I prefer to continue working on iArcade's current branch, under IPB 3.0 - Making sure it *works* on IPB 3.1, but not building in new features. Once iArcade reaches a stable point, I will shutter new development for it, and move into iArcade 1.1, for IPB 3.1, without any backwards compatibility.

Now that my "plan" is laid out, so to speak - what do you guys think?

ok and I hope you are not pausing the development at all.

[Joe D]

Great plan Collin, take your time and get it right then move forward. No need to be chasing 3.1 until it is stable.

[Chito]

Now that most of you have voiced yourself, I'll post my side of things: I prefer to continue working on iArcade's current branch, under IPB 3.0 - Making sure it *works* on IPB 3.1, but not building in new features. Once iArcade reaches a stable point, I will shutter new development for it, and move into iArcade 1.1, for IPB 3.1, without any backwards compatibility.

Now that my "plan" is laid out, so to speak - what do you guys think?

I read through everyone comments on this and I too have to say that I agree with this plan of yours Collin. No need to rush into IPB v3.1 yet. Stay on course, take your time to make sure all is well with the current v3.0 :cool:

[AngelFire]

yep i agree with to :)