eBux / eStore's Future

I'm sure people have all read about the 'ebux' being Trademarked in the USA & Canada.

First off, let me start off by saying that this really sucks. But it's really my own fault for not researching it before creating eBux / eStore. It will cause a lot of headaches I'm sure in the future.

SO if you have been following the progress at http://www.ps2hits.com/forums/ then you will notice that eStore is no longer in existance. Now before you start to cry, you would also have noticed that vBux / vStore is in place of the old eBux / eStore.

vBux / vStore v1.5.0 is up and running at the above test forums. Now I can not stress the magnitude of the testing thats needed before this version is released out in the wild to the public.

I'm doing everything I can to make it save as MUCH as possible. But there will be some things that you will have to resetup. I have done a lot of the conversion coding already. I must say that the conversion I've done so far is gearing up quite NICELY. I'm proud of the coding for the update, which I can say a lot, I am usually not proud of coding that I make, but it gets the job done normally as well.

I have added a revolutionary change to the forum table that all vB mod coders will take note of. I do not think that this was ever done before, if I am wrong, I apologize. I have added a "bitfield" to the forum table. Yes, just like the <bitfield inside of bitfield_xxx.xml for the Usergroups.

It took 4 plugins to do this and when v1.5.0 is released, we may see other hacks start to use settings like this. So what does this mean to you, the end user?? Instead of eBS using 11 fields inside of the forum table, vBS will only use 4 fields inside of the forum table, aka less data to cache and save. And now that the foundation is layed for this, I could add some more forum options that should make things interesting as well.

The fact is, vB.com could do some modifications to make this more streamlined in the future, check out the following code:

Inside admincp/forum.php

	foreach ($vbulletin->GPC['forum'] AS $varname => $value)
	{
		if ($varname == 'options')
		{
			foreach ($value AS $key => $val)
			{
				$forumdata->set_bitfield('options', $key, $val);
			}
		}
		else
		{
			$forumdata->set($varname, $value);
		}
	}

This code is inside the block where it checks $_POST['do'] == 'update'. Instead of checking if the varname is equal to options. They should check if the field type is a bitfield type. If they would check if the field was a bitfield and then run ->set_bitfield for the varname found, it would mean 1 less plugin and/or hack has to be done.

SO if you use a bitfield with the current vBulletin 3.5.4, it will save all of the fields as separate variable names. SO I have devised a very small chunk of code to do the following:

	// process all of the vbsforumoptions
	foreach($vbulletin->GPC['forum']['vbsforumoptions'] AS $key => $val)
	{
		// set this bitfield
		$forumdata->set_bitfield('vbsforumoptions', $key, $val);

		// unset the one set previously by vBulletin
		unset($forumdata->forum['vbsforumoptions'][$key]);
	}

With this, you can see my custom bitfield is named vbsforumoptions, and you will notice it does UNSET the previous one that is set by vBulletin, so it will function properly. vBulletin.com, if you could update that code in forum.php to allow mod makers to use bitfields, that would be great

Even if they do not add this ability in the future, the fact remains that the above code will work and it is fairly optimized.


So the bottom line........

When you see the coding for the new Product XML sheet for vBS. You might look at it and say "its HUGE", but in reality is quite small for a task of this magnitude. I have renamed all of the phrases, all of the template variables, all of the variables/tables/fields inside of the PHP files. Basically any and all reference to ebux/estore have been changed to vbux/vstore and the tables/fields have been changed to vbs_table or vbs_field to better recognize which fields are for use with the new vBS. It's a MUCH better organized system and should allow for much easier to understand core code to build addons for.

I know this post seems a little long winded, but its necessary for me to tell you that when the aftermath settles for vBux / vStore .... everyone will be coming out on TOP.

-CMX

[djjeffa]

I was thinking of install ebux/estore, do you recomend I wait?

[Reeve of shinra]

Having to rebrand sucks but thank you very much for continuing to support what has to be one of hte most extensive hacks ever made.

[CMX_CMGSCCC]

Well, if you wait, you avoid any templates that have to be changed, it should be coming out in the next couple days.

Reeve: Yes, but what else choice did I have? :x

-CMX

[moonclamp]

I'm happy with the way mine is running now.

My main worry is that if I upgrade my users will lose points or features they "paid" for.

Would it be worth sticking to the current version because of this, or is there very little chance of this happening?

[OAndrea]

I am new to Vb and hacking and extensions and all this stuff, but I have to say that this hack has been the best. I am super impressed by how much you have done in so little time. Thanks for all your hard work! The store ROCKS and I am positive the vbux/vstore is going to totally kick booty too!

[MorrisMcD]

Trademarks suck!!!

I am patient with the current ebux.. Take your time and lookin forward to the new one..

[CMX_CMGSCCC]

Thanx for supporting the cause!!

If you upgrade PROPERLY, you will not lose settings the members have purchased.

The proper will to upgrade will be to first INSTALL vBux / vStore, then Uninstall the old eBux / eStore.

-CMX

[ImportPassion]

I REALLY don't think you need to worry about the trademark issue.

[JsnakeJ]

Its not worth the hassle if it does become a problem, thats why hes doing this.