CMX_CMGSCCC
03-05-2006, 09:49 PM
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
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