What is DocBook and the Advantages?

DocBook is an XML format, which allows for creating documents independent of any one presentational format, like for example (X)HTML or PDF. The focus is on the content and the fifth revision of the format allows for a lot more freedom for mixing XML namespaces, so it is possible to mix in XHTML when desired.

However, the advantage of writing in the DocBook format, is that it allows for easier translation. They only need to focus on the content between the DocBook XML tags and can easily convert the DocBook to XHTML or a PDF from that one format.

The other advantage is that with the latest revision of the standard has a project that works with DocBook, which allows for displaying the DocBook in XHTML format to see what the final product will be. Aside from the XSL project, I’ve found that converting to other formats are quite a bit more involved.

What is an User and Developer Manual?

The User and Developer Manual concept is very simple: you want the very brief, basic information to give to the user on every aspect of the application. Sure, it won’t be able to walk them through every possible use case, like the WordPress Codex would. Sometimes, you only need to shove the user in the right direction and the user will be able to figure the rest on their own.

That is the concept should allow for some what quick turn out when there is a new release, once the finish product is complete for the first time. Between each release, how much really changes? A few things sure, but the user functionality largely remains the same. Therefore, once the manual is complete for one version, you can just update the pieces that changed and add new sections on new features that were added and release the updated manual for that version.

So you would always have a manual for that version. When you compile the XHTML site and/or the PDF for that WordPress version, you can always release that version. When the next version comes out, you can just release a new XHTML site and/or PDF for that version. So, you would have both versions available for those who are slow to update but still want information on the older version.

The Hard Part

The hard part is filling the User and Developer Manual with content the first time. Also, if there is a major overhaul, then it will mean that major portions of the document will become obsolete and need to be rewritten.

However, I think that if such an effort were made, then it would have some merit to charge for such a document. Whether anyone would buy such a product is yet to be decided. I think in the spirit of WordPress, it should be free as the software is, but I find motivation for such a long and tedious project hard to come by when everything is done for free.

My Goal

I still plan on creating the User Manual, because I still need to do research on DocBook format and become competent in the format, so that when I need to use it for my projects, I have experience on what doesn’t work, what does work, and what the visual output will be while the document is being written. Also, I need to learn how to change the layout and design of the DocBook output, using either the XSL and PDF.

I want to learn how to create both the XHTML site and PDF and writing the WordPress User Manual will allow for enough motivation to actually accomplish that goal. If I can find enough people to continue the project or help out, then I’ll have the manual as completely free and GPL. Well, it will be GPL anyway, but I might decide to charge for the PDF.

Content

The content will consist of text (of course), pictures, and video. Going over the video capture software, I think it will be quicker, faster, and somewhat easier to build the entire manual in multiple screencasts and then use that material to create the content in the User Manual. People will value the Videos and of course the search engines will pick up the content and pictures.

I want to put all of my raw content out there for anyone to use, so that when I leave the WordPress community, someone can reuse the content to take off where I left off. I also want to give the RAW video feeds, so that someone who has a better voice or speaking ability can do a better screencast based off of my videos.

It will be a nice experiment and I look forward to it. However, I’m thinking it will be a Fall project. The Developer Manual portion is a lot more involved, so it will be free, based in parts off the WordPress Codex, and be GPL. I want to have every component in WordPress detailed in the manual and it probably will be a lot more focused with examples and more content.

I’m more torn on the Developer Manual, because the purpose will be more geared towards allowing ease of translation than anything. It belongs on the WordPress Codex sure and I’ll probably build the majority of content on there before converting it to DocBook. I’m thinking of using the WordPress Codex as the planning and organization of the DocBook, before I compile the content into the DocBook format.

Possibly Related Posts:

• Calibre Improvements
• DragonU Bug Tracker Dev – Milestone 1
• Dragon MVC
• Why I Contributed to WordPress
• DragonU DB Component

I’ve been playing around with this idea for a while and I think it would be very interesting concept to complete. The concept is simple and most of the code will be easy. The concept part is take what is most often used and least optimized and rewrite it in C/C++. The easy part is that you can sort of do similar coding structure, albeit with pointers and zvals, but the code can be structured in the same way, well mostly.

The disadvantage of taking an almost 1:1 approach from PHP to C/C++ is that the result code may only be slightly faster (between 15% to 30% increase of performance). Comparable, it might be even faster to instead use C and C++ to the full advantage and use algorithms based completely on them.

However, it would be interesting to enable the Plugin API to execute in linear time with some of the logic. The Plugin API would be a really great first testament of the PHP Extension and it would be interesting to implement other features within it. However, I think just having every function within C/C++ would be a good initial effort.

The initial release has to be released quickly, be optimized as much as possible. If you don’t optimize the C code as well, then you can have just as bad performance. It should be fun, but I hope that I’ll have the fortitude to actually finish the plugin API part to enable benchmarking between the PHP and PHP Extension.

Possibly Related Posts:

• Game Engine Development and Open Source
• Plans for Base CMS
• Project Plans
• Calibre Improvements Part 2
• Usability Testing Software Development

It is nice that WordPress 2.6 is not due until August. I was thinking that I would only have a single month for my pet projects, but I’ll have more than two and a half months to finish what I need. I believe with that amount of time, I can polish the patches I made in January and provide better arguments for inclusion into core.

Inline Documentation

Also, the biggest project will be finishing up the inline documentation for WordPress wp-includes folder and the wp-admin/includes folder. There might be functions in other places, as well as adding file level phpdoc documentation to files, but those won’t take very much time. Going forward, I believe it will make sense to document everything else that remains in 2.6, so that developers understand that each new function needs to be documented before it is committed.

Already several core commit team members are adding phpdoc inline documentation to new functions. However, not every core team member is doing so. I believe it will be easier for the community to provide patches for these mistakes, but not everyone is going to care and if care is not taken then a similar problem in earlier versions will appear in later versions.

I don’t want to see, two years from now, many functions which aren’t documented.

I’m thinking I can finish the inline documentation before June, but I would have to work every day, plus weekends to complete everything. It usually takes about 16 hours to document the bigger files, like functions.php, etc, and 8 hours for some of the smaller files. I’m not sure how much time I’ll devote or when I’ll start, but it is something that only has 20 more files to complete in the wp-includes folder, which is the most important to complete. So it would take around 10 days, if I worked 24 hours nonstop, which I’m not going to do. Well, I’m going to have to try for the second week of June for completion. For the wp-admin/includes folder, I’ll have to add another two or three weeks.

I probably won’t be finished with this project until July.

Writing Test Cases

This isn’t part of the WordPress repository, but it does go with it. I’ve stated before that my intentions were always to complete the inline documentation for WordPress and then move on to help write the test cases for WordPress.

The neat thing about writing test cases is that eventually, you’ll come across a bug and will have to write a patch for that bug, or at least seek out bugs that currently exist and write test cases which test whether or not that defect is accurate or not and provide a patch for it.

The goal of this mission, is to clear out most of the defects in Trac and try to make either WordPress 2.6 the most stable it can be, or at least WordPress 2.7 the most stable. It just depends on how long writing the inline documentation will take. Most likely, I’ll only have less than a month to start writing test cases and get patches in, which will put the WordPress 2.6 release somewhere in the beta and RC release stages. Not a good time to start, so at least WordPress 2.7 will get the most patches from the work.

The goal is to write as many test cases as needed for as many functions as possible and writing patches when needed.

Another possible goal is to write test cases for the enhancements, as to whether my patches actually succeed in adding the enhancement. The goal then, will be to get the Trac tickets to less than a hundred with it primarily consisting of enhancements and tasks. However, this is optimist, but really the community as a whole will provide the majority of patches.

The secondary goal is to reduce the overall amount of Trac tickets.

Google Summer of Code

You know, I would really like to be accepted into this program, but I’ll have to finish as many files with inline documentation before I start and it will probably throw off my above timeline. If I’m accepted, I’m going to spend the majority of my time working on whichever project I’m accepted for.

This really means that I’m probably only going to work on the phpdoc on the weekends, but for only a few hours, so it will slow down my timeline for inline documentation, but I still hope to have all of the files in wp-includes finished before WordPress 2.6 is completed. If I’m accepted it will also look like I won’t even get started with writing test cases until the Fall, which will give me a lot of time to devote to writing test cases for both WordPress 2.7 and up towards 2.8.

OTC Spring Semester 2009

If I’m graduating this Spring, then I’ll be going back to school next Spring to start my Internet Application Development degree. I do not plan to be active in the WordPress community at that point. I might come back to write test cases and inline documentation when needed, but if my above projects are completed, then I don’t think there will be a need me any longer.

Therefore, I’m thinking ahead to creating a photo gallery application or joining Zen Gallery project. I also look forward to fixing Mecha Asylum and rejoining the Asylum Futura project and releasing Mecha Asylum as a branch to that project. There are a couple of other game projects that I hope to work on during the school year (which really shouldn’t be difficult, since I’ll already have my core classes finished and would only need to complete the degree classes.

I’m probably looking at three semesters, depending on whether I go for full time or part time. However, I’ll be paying for everything, so I’m pretty sure I’ll only be taking a few classes at a time to not break the bank.

Regardless, I do think I’ll join the WordPress community again in the future, but it probably won’t be until I have gained progress on my other projects, like DragonU.net, AbsidonGames.com (which I want to be able to have repositories for, with Trac and eventually continuous integration), SantosJ.name (not just a blog anymore), and the browser game projects. Well, besides the browser game projects, which take about a three months to develop, the other projects could be worked on and completed throughout the 2008 year.

2008/2009 Plans for Sites

Mostly with DragonU.net and AbsidonGames.com, I want to switch them over to WordPress as the CMS and use it for the pages and designs. That way, I don’t have to write a custom administration panel for the sites and will have everything I need to allow other people to manage the site along side with me. I’ll also be able to write plugins for the rest of the authors and modify the themes. I’m probably going to use my current theme that I bought a few years ago for several months. After that, I’m going to buy a new theme or try to get a new custom theme for both sites.

AbsidonGames.com is a bigger project in that it will require adding Trac support and probably a plugin which allows for adding members of the blog to the Trac and Game Repository System. So everything will be managed by WordPress and who has access to what. It can be done in stages, which it probably will anyway, but I want all of the game sites on my hosting server to use Subversion and not FTP. However, to do so, I need to be able to allow new users to sign in and register automatically.

AbsidonGames.com will provide the news network, so that someone would only need to go to AbsidonGames.com to see what is being developed. Also, the games will grab the RSS feeds for their news section, completely replacing the need to have a news administration panel in the games. There will probably be one anyway, but probably not for adding news, but managing which feeds are added, as well as which news items are shown.

SantosJ.name just needs a photo gallery, my resume (probably just link to linkin along with a printable site version), as well as a picture of myself. I’ll probably also go through all of the articles I’ve written and either expand upon them to create something bigger or tag them. I’ll probably want to extend the Browser Game Development articles I started to write, since they get a lot of traffic.

I keep saying that I’m going to improve these sites, but never seem to get around to doing so. I think also for Absidon Games and DragonU, that the biggest time waster, was the custom CMS that I built. I think going to WordPress will save a lot of time and allow me to focus on just the content and additional features, instead of working from the ground up.

Possibly Related Posts:

• Bullet: E-Book Library Management and Content Server
• Using ZendFramework 2 beta1 For Directory Project
• The Way of Kings and Cosmere Theory
• “In Time” Movie Premise Flawed
• Completing HTTP Library For PHP

I have had several ideas to add to WordPress that I want to finish before I move completely to some other projects. I’m thinking if I get most of them done before 2.6 is started and 2.5 is out, they’ll be able to get in WordPress. That is a dream, and I don’t have commit access, so it is totally up to the commit team.

HTTP Request and Post API

My idea for HTTP Request and Post API is finalized, except that it has not been included into WordPress. I’m unsure why that is, since I have included, both documentation and unit tests that covers the full extent of the library. I also stripped out most of the extraneous material.

I’m about ready to do a complete and major overhaul of the system, once again and see about instead creating a set of functions which is pluggable, instead of classes, which do the job. It would be less flexible, but I think the change will be more the way that the devs would like it. It stands to be as long as wp_mail() however.

The last test I can do, is profiling the code, to make sure that it is quick enough now to work in WordPress. If I do that and I prove that it works and doesn’t create too much overhead, I’ll be seriously pissed if it doesn’t get in.

WordPress Logging API

I did some initial work on a WordPress Logging API which will capture all notices, warnings, and errors, and have them logged to an array for a plugin to later access and do what the plugin will with the array. This will first disable displaying of PHP errors and notices and will secondly, allow for better debugging, both on a live system and on a debug system.

The API is complete and I’m unlikely to do any major overhauls on the system. I think the next step is to focus on major areas that could use the API and convert them over to using the new API. I was hoping to get the API in 2.5, but I think major areas could also be switched over to using it.

I’m thinking I’ll focus more on getting the API in 2.6 and do a lot more work on converting major sections and other logging sections over to the system. I also will need to do profiling to make sure that calls don’t cause too much overhead.

Controller API

WordPress already has and uses the controller model, but it is not easy and is convoluted in many places. I would rather create a system which the WP_Query and Rewrite is combined in areas and allow for an easier model for adding pages. I would very much like this idea, but I don’t see myself creating it for 2.6 and I doubt it will make it in 2.7. I’m thinking that with the amount of time I can spend on it, it might see the light of day in WordPress 2.8, if the commit team is fine with replacing the rewrite and query model.

Single Use Form Nonce Tokens

The current nonce form token system is lacking in some areas and I would rather see some additions that allow for replacing CAPTCHAs, but are safe enough to be deployed in public systems. I would rather this also be in WordPress, so that each plugin doesn’t have to create their own system.

I have the code, however, it is not licensed for use in GPL, so I’m going to have to rewrite the code for WordPress. I am also going to have to write some unit tests also. It will require going to a session based setup instead of a cookie based one. I believe, my plans for having it cookie based also has it use sessions.

I should note that it isn’t completely secure, but it should halt most of the lesser intelligent bots. I person would be able to defeat the nonce easily, but would require a lot of work. Spammers would not be interested, hackers probably will be.

New Plugin Architecture

There has already been discussion on this and I think I’m over not being able to get it in 2.5. I think having it in 2.6 or 2.7 is fine and I’ll be willing to do work on it for 2.6 during any downtime. However, I do think that this is probably medium priority on my list. It would be fun to write, but I want to get some of the easier and more complete components finished first.

Possibly Related Posts:

• Bullet: E-Book Library Management and Content Server
• Using ZendFramework 2 beta1 For Directory Project
• The Way of Kings and Cosmere Theory
• “In Time” Movie Premise Flawed
• Completing HTTP Library For PHP

I would totally love it if WordPress had all of its functions documented. It could put WordPress with higher respect with developers. A lot is put on with the Codex, but the Codex is unstructured and doesn’t cover the complete depth of WordPress core and outer edges.

It is true that pieces can be picked up with the codex and trips to the code would allow others to pick up the rest. The WordPress API isn’t as difficult as some applications, so it has done without and flourished without a complete function documentation for a while.

That should change and is changing. However slow, it is quite boring to write documentation and depends on the mood. Realistically, it is very easy to get bored of it after working on it for a few days only to jump back on after taking a break of a few more days.

Documentation Process

For me, the way I’m now writing the documentation is by first going through and adding PHPdoc style documentation to all of the functions and then going back and adding @since information. Well the complete process is as follows.

1. Add phpdoc style documentation going down the file to all functions and others that can be documented. Usually just a template which I copy and paste.
2. Going back up I add the function name as well as @since
3. Going back down I try to add short description information if I can, but definitely the parameters and return type information.
4. Going back up I complete as much as possible the long description, but definitely the short description.
5. The long description that is still needed, I usually ignore until it either comes to me or I want to finish the documentation for the file.

It might not seem like much, but on average documenting a function can take anywhere from 10 minutes to between 30 minutes and an hour and the more difficult and longer functions.

Old Style Documentation

There have been attempts to document the code before, but the extent is no where near the level of the documentation process. It is likely that because documentation does cause minor overhead to the PHP execution that a lot of documentation would slow WordPress down. However, that should not keep the documentation from the core.

If someone really cared about removing overhead from comments, then they’ll most likely do premature optimization and remove as much white space as possible also and combine as many files as possible. Premature, as the most overhead is likely with the database.

A few projects have noticed an increase and so have a build environment which has the comments, nice format, and split into multiple files and then through the build process compress and combine the files. If someone wanted to squeeze a few milliseconds, then be my guest.

The Roadmap

To me, it would be a pipe dream to think that all the functions in wp-includes would be documented before WordPress 2.4 comes out. However, I would very much like to complete the documentation in the folder before 2.5 comes out. In that way, the core development team can keep up with documentation themselves and the hardest part would be complete.

The team has started to make sure that any new function that goes in gets documentation, which should stop the flow of undocumented functions. However, it would be better if more people offered to help with the documentation. The standard is there and the support is there.

WordPress 2.4 is moving the business logic from the presentation layer in the admin panel backend. Therefore, those functions should also be documented. Hopefully, I hope to also have those done before 2.5 is out also, but going off what I have currently done and how much I have to go to complete wp-includes, I’ll be pushing for WordPress 2.6.

After the Function Documentation

I plan on focusing more on the unit testing and DocBook type documentation. It would be great to get WordPress to the level where has complete unit test coverage of the WordPress functions. Covering regressions, as well as bugs.

It would put WordPress on a higher level with developers, in my opinion, if I know that whatever code I applied went through unit tests to make sure it didn’t cause any regressions and actually fixed problems.

There is someone working on this and since it is supported by Automattic, should be continued without outside help. It would move the test coverage along if more people helped out, because user testing can only pick up so much.

The next step after the unit tests or automated tests, is acceptance testing. Which would automate portions of problems for users and test for common failures.

With an comprehensive WordPress User Guide and Developer Guide written in DocBook markup, it would allow easy access to common answers to users’ and developers’ questions. It would also remove the need to traverse the sometimes difficult to navigate codex. The guides would also be condense enough to provide pin point details instead of trying to describe everything as much as possible. With shorter amount of text, more people will be more willing to actually read through the sections to where they need to go.

WordPress Documentation Plans

The codex is not bad, but it can be improved for both developers and from the work on the user guide and developer guide, long portions should be moved back to the codex to allow for further modification and improvement.

The best thing about the DocBook User and Developer Guides is that they are completely translatable and multiple versions can be available on the same site for those native users. The User and Developer Guides would prevent translators from having to translate the huge amount of text in the codex to provide simple answers.

It is a hope, but there is only so much time. My attempt is basically to jump start the process, so that others that come after me won’t feel as overwhelmed as I do now. To my knowledge and to those that came before me, I believe they also shared my hope. It might have taken one or two years before I came along and put forth a small amount of effort. However, if I don’t get the documentation finished, I believe that some awesome person will come after me and finish what many others have already started.

Possibly Related Posts:

• Game Engine Development and Open Source
• Plans for Base CMS
• Project Plans
• Calibre Improvements Part 2
• Usability Testing Software Development

I think for as much coverage as possible the following should be done for encompassing the whole of WordPress using tests. The PHPUnit version 3.2.0 should include many new features that should allow for better testing WordPress in environments more true to XP programming techniques. Along with PHPUnit, I have been meaning to build a site for statistics, but I think it will come later when I have more tests done.

1. Unit Tests and Characterization Tests.
2. Hook Tests
3. Database Tests
4. Acceptance Tests

Unit Tests and Characterization Tests

There aren’t very many functions or library files that allow for true Unit Testing, so I would rather combine the two tests, instead of trying to keep them separate. This would allow for coders writing tests to not worry about whether the function can be unit tested or have characterization tests. Comments should be made for the methods on what is tested to let others know if the test is an unit test or characterization test to the knowledge of the author.

All actions and filters will have to be disabled while running the tests to allow for just testing the functions. Testing the hooks would be done separately. Looking through some of the bug reports, it seems that some hooks are required to test for some obscure bugs. This should be done in the next section.

The unit tests and characterizations tests should be run by themselves, separate in execution from the rest of the tests. I have also been meaning to remove dependencies on my changes. I think that since the last WordPress commit, that is no longer an issue.

Hook Tests

Remove all filters and actions and manually add the hook workflow to test the result. This would require mock functions that duplicate the functions or running the full version of WordPress, except for the output.

Testing the hooks has more to do with regressions and refactoring of hooks, since hooks should work as long as the plugin test passes.

Database Tests

PHPUnit 3.2.0 will include DBUnit which will allow using a snapshot of the database and test output using that instead of a real database. This should be extremely helpful in testing Database Queries.

Acceptance Tests

Test the blog site to make sure that everything appears correctly.

Possibly Related Posts:

• Calibre Improvements
• DragonU Bug Tracker Dev – Milestone 1
• Dragon MVC
• Why I Contributed to WordPress
• DragonU DB Component

I’m updating the Design Document since I won’t have enough time to do everything I had in the first document. The primary focus on this version of the game is just for PvP for players and allow them to gain experience and get new powers and skills. The goal is also to defeat other players in the dragonball universe. I’m going to list the features and areas that I want to have for the players.

Market

I want to allow players to buy supplies here. I also want to allow the players to equip weapons and armor. The focus won’t be weapons and armor but it would still be pretty cool to include them for those that want to have it.

Status

The Status page will list what powers the player has, what attacks have happened to the player. The Navigation will also hold status about health, money, and Ki levels. Also lists the alignment the player is on.

Money will be awarded to the sides that have more wins than the other. That means that if the evil side has more wins against the good side than they get the full $100000 for that day and the other side only gets $50000 for that day. Money will also be given in the training modes and for defeating the enemy.

Training Center

The training center will be the same as in the old Design Document.

Groups

Groups provide added protection to its members so this means that if one member is being attacked than the other members will jump in and help out. That is not to say that everyone in the group will be protected all of the time. It just means that if there is a battle, there is a chance that another team member would jump in. Other team members can also help out with an attack.

Attack

Attacking will be the same, as in the old Design Document.

Possibly Related Posts:

• Calibre Improvements
• DragonU Bug Tracker Dev – Milestone 1
• Dragon MVC
• Why I Contributed to WordPress
• DragonU DB Component

School is starting again, and I have nothing done that I wanted. I did work some things through that are really cool but the Dragonball game is no where near completion. This week I don’t have to work that many days so I have that time to try to catch up and get at least some of the scripts done. I want to at least add the powers and training rooms to the completion list.

I have also decided that I need to write a more detailed report for each part of the Mecha Asylum game. I also want to write about the RPG mode of the game. The reason for all of this planning is that I want to have a set goal to follow and then decide what works and what doesn’t and try to make everything work together. I have also decided that a lot of the internals will be the same for both modes. The player will just do things differently and focus on different areas. I want to have the market work the same way for both modes for example. There is also the matter of the stories for both of the modes, which I need to write.

I guess, I should probably write about the areas and what the RPG and RTS mode will be about and the different areas that I plan on building. It would be a start and a plan for creating the game.

I also had a plan on building the Mecha Asylum game and Dragonball game side by side and working on each parts at different times. I don’t know how that will work out but it couldn’t hurt to try it out for a while. The problem is that, if it doesn’t work out, I have to finish the Mecha Asylum game before I go back to the Dragonball game. There are a lot of angry people asking for the dragonball game and I think all they really want is to just play around with the powers and gain levels and what not.

Possibly Related Posts:

• Bullet: E-Book Library Management and Content Server
• Using ZendFramework 2 beta1 For Directory Project
• The Way of Kings and Cosmere Theory
• “In Time” Movie Premise Flawed
• Completing HTTP Library For PHP

The problem is that, I have wasted a lot of time doing other things and haven’t worked that much on the Dragonball game. It is coming together but is no where near being playable. That being said, I need to start working on Mecha Asylum. What I plan on doing is working as hard as I can and trying to complete the basic features of the Dragonball game and allowing people to attack each other. I will most likely come back to the Dragonball game in the summer when I will have a lot more time to work on the game and make it the level that bobman and I want.

The reason Mecha Asylum takes priority is that it will include premium features and I would very much like to make money off of my hard work. I mean, I won’t make much from the game but a few dollars here and there will help out and would be nice.

Possibly Related Posts:

• Calibre Improvements
• DragonU Bug Tracker Dev – Milestone 1
• Dragon MVC
• Why I Contributed to WordPress
• DragonU DB Component

Moves

Techs are techniques you can learn, they are different from attacks in most ways.
-Dragon ball Creation-: A free one time only tech, given to new guardians of a planet, they create dragon balls, and either give one of them to specific people, and/or spread them out so you have to use the radar to find them

Flying: Allows you to fly [1,000PL]

Sensing: let’s you sense PL’s and energy on a planet without a Scouter. Cannot sense PL on a different Planet [2,500PL]

Instant Transmission: instantly move to another place you can either see, sense PL at, or have been before, Travel from planet to planet is prohibited to one planet per day need sensing) [250,000PL]

Hologram: Creates an exact replica of you (1/2 your current PL), lasts one battle, or one training session [100,000PL]

Fusion Dance: you and a partner fuse, your PL gets added to the other persons PL, your name gets re arranged, the person with the fusion move gets control of the new character, lasts one battle then the characters un-fuse [5,000PL]

3-Way Fusion Dance: Same as above. All three that are fusing must have Fusion Dance, and two must have the 3-Way Fusion Dance [500,000]

4-Way Fusion Dance: Same as above. All 4 must have both the Fusion Dance, 3-Way AND the 4-Way Fusion Dance [5,000,000]

Kio-Ken: Your current PL is x2, can only be used one battle a day And can only be used in your basic form. And yes, your PL from Kio-ken gets multiplied when you change forms. (Androids excluded from this rule)[25,000PL]

Moon Blast: creates a full moon, (saiyans only) [100,000PL]

Bribe: you pay 500 Zennie to your opponent and somehow “win” automatically Must have more than 500Z to perform (cannot be used in deathmatch) (humans only) [1,000PL]

Absorb: Absorbs energy Permanently from a ki shot at your or from others by grabbing them, In training you may absorb one Life-form (5pl) (androids only) [5,000PL]

Regeneration: regenerate any lost limbs and health in combat, can only be used to heal once per battle, and you heal 1/2 of your base pl. [Can be used in and out of battle] (nameks only) [50,000PL]

Kakastune: You fire a ki balloon at your opponent, it engulfs them, leaving them open for a turn (Changelings only) [10,000PL]

Strike Fear: You become a monster and freeze your opponent in fear for 1 turn ( X race only) [10,000PL]

Possibly Related Posts:

• Calibre Improvements
• DragonU Bug Tracker Dev – Milestone 1
• Dragon MVC
• Why I Contributed to WordPress
• DragonU DB Component