The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
UPDATE: vBulletin 3.5.0 & RPG IH Details »» | |||||||||||||||||||||||||
I have seized all further development of the RPG Integration Hack to release a vB3.5.0-compliant version. For those that don't give a flying fk about the details, this basically means that you will see RPG v3.5 (no pun intended) with the already present features, plus the features listed in bold in the Suggestions for future version thread, under the "Approved feature suggestions" section.
As for an ETA of this new release, I cannot tell. I want to clean up every single template and remove redundant templates before I release it. My summer holidays started, so I will work day and night (almost literally) to release this version ASAP (but with as few bugs as possible). Now for the details. I have not yet seen the vB3.5.0 code, as the zip is sitting, downloaded, on my desktop and me almost too scared to open it. I need to upgrade my localhost, and make sure I got all the v4 edits down on paper before I want to do any more work. I also need to learn the new codes, and how to best utilise the plugin system. I promise you, I will do whatever I can to make sure file edits will be kept to the absolute minimum. IF your new vB3.5.0 will remain a hassle to upgrade due to sloppy coding, it will NOT come from the RPG. Also I have a confession to make: Even though I bolded the Cache system feature, it is not 100 % complete. I have yet to design and code the Inventory control itself, and to update the Battle/Monster Arena with this new cache system. The latter should be a piece of cake, but the Inventory may take some time. It will be ready within the month, of that I am almost sure. Again this depends on how complex the new coding is. That's about it, if you have any further questions about this issue, feel free to ask Show Your Support
|
Comments |
#2
|
||||
|
||||
2 months later. Curious to hear about the current status
|
#3
|
||||
|
||||
Well, the cache system turned out to become abit more extensive than I first planned.
I also didn't like what was happening to the functions in the new OOP style, so I have basically rewritten the entire core. Again. There's just a small amount of coding remaining to be done there, then I can get started on the actual files. Now due to this new system being so different from the old (the "old" being a system that basically never made it to the public), I have to rewrite parts of every file. Therefore, remaining to do is as follows:
|
#4
|
|||
|
|||
If you need any help with general PHP, feel free to get ahold of me by PMs - I don't know vB 3.5's architecture yet (But I plan on learning it once I get around to it ), but I do have a few years experience with PHP
(This reply was a pathetic excuse in getting you to post an update - while actually offering help ) |
#5
|
||||
|
||||
What is the projected amount of files you see being added?
|
#6
|
||||
|
||||
Quote:
Quote:
As for a general update: Development has been nonexistant for a few weeks now. Ive been busy with a paid mod, and in the meantime combatting my Lineage II addiction. The entire core is being rewritten (again, for the 3rd time and counting ), but this new structure offers cleaner code, ease of use for developing extensions/addons, and query efficiency. For instance, in headquarters.php, you had the potential of having the script run an infinitely large amount of queries, depending on how many combinations of class/race/element etc you had available. This has been reduced to zero, due to the cache system I blatantly ripped from vB... eh I mean wrote. In any RPG file (IE not vB default), no queries need to be ran to fetch Clan, Class, Element, (Gender), Item, Race, Type. In short, everything that would need to be involved in a massive query to fetch all required info. In any vB default file (ie showthread, showpost), hooks will take care of the fetching of this info. I am looking at a very high probability of there being NO file edits required, though this might change when I move on to the admincp. In general, the only file I have finished is headquarters.php, though this will need slight rewrites because of some key changes to the DB table names I plan to introduce. Ill try to make some time each day to developing the hack. I feel confident Ill be able to release the 3.5 compatible version within 2005, though this may change at any time. My sig will be updated should I have reason to believe I won't be able to make the deadline. |
#7
|
||||
|
||||
Quote:
|
#8
|
||||
|
||||
I plan on making every bit of the hack that CAN be made AJAX compatible this, but not in the first vB3.5 version.
I mainly want to make the hack even more efficient, and 3.5 compatible first. Then I want to finish all the features I have listed for the 2nd version, and then I will either work on making what I have then AJAX compatible, or start coding the "next generation" version (3rd eta in my sig), which I am getting designed by a professional game designer. I particularily want to introduce AJAX in the Battle pages, to avoid page reloads. |
#9
|
||||
|
||||
So in a sense the system is moving more towards realtime then turnbased?
|
#10
|
||||
|
||||
I don't want to go into details on that, because that would be telling
But I can say that I won't make any drastic changes to the battle system without offering an option to revert to the old method (but still be able to utilise AJAX and all other features, of course). |
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
More Information | |
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|