That's because help files in general suck!

I am disturbed by how insensitive people can be online. After dealing with a weird issue regarding my custom Qt5 based gaming database project, I was extremely happy to learn that my stupid issue that has stolen lots of hours of research and obfuscation was finally CLEAN UP during my latest code update! Now I can see my custom widget hold all the window elements I want it to hold till you close the application. I revisited my help request topic on stackoverflow only to find out they closed it then placed it on hold right in front of this poor victim because they thought it was misleading somehow. Even so I had to complain, I was about to post my very own solution to my issue at that very same moment! I had to leave a summary of steps I have taken hoping they won't edit or block it or erase it or do anything else against it. They even dared to steal a reputation point from me!

Then I recalled why I had once left that site frustrated a few years ago...

Okay... I just spent nearly all my time today working on a new help file for my new Animated Battlers system. I want ti to be easier to understand than the other one. But that's going to be tough.

There are differences already, one being a separate chapter just to describe the various types of battlers one can use. Do you know what the differences are between spritsheets or spritestrips? When did spritestrips come about? What were the oldest games that even used battlers? A primer course, a glossary, a comprehensive scripters guide, and more.

Awww.... I haven't even touched the configuration sections!!!!

Wow... that's a lot of typing....

Huzzahs and groans combined, I have just finished entering in and describing every method used within the Sprite_Battle class for this new Animated Battlers help file. THAT'S OVER SIXTY METHODS I HAD TO DESCRIBE! OVER SIXTY!!!! IT TOOK HOURS TO PROPERLY DESCRIBE THEM!!!

As I said, Huzzahs and groans, right? Well, I have not tackled the methods I have within Scene_Battle. And there are exactly sixty methods within to describe as well. All this while I've been putting off going into the actual instructions on configuring Animated Battlers. Wow, can anyone say intentional procrastination? Oh, wait. I just did.

Well, unlike other help files, I know that the Q&A section will probably be jam packed. Seriously, I took over for Minkoff back in 2006 and was asked countless requests and inquiries how to use the system. Granted, there were many times the same question was asked over and over and over again... and over again... and again... But I must have a good supply of questions to use, right?

Oh, and there's a section in the help file that talks about a few battle-systems that I have encountered that I know works with Animated Battlers. Of course I know they work, I host demos for nearly all of them!

(10-25-2018, 03:34 AM)DerVVulfman Wrote: As I said, Huzzahs and groans, right?  Well, I have not tackled the methods I have within Scene_Battle.  And there are exactly sixty methods within to describe as well. 

More Huzzas!   I just tackled the Coding Reference chapter, now holding the description of roughly 140 methods.

I also grabbed and saved over 20 web-pages from Creation Asylum, chronicling Animated Battler's early years from 2006 up to more relatively recent postings.  That should supply me with some good material for the Q&A section.


I still have the Configuration section to take care of...  more procrastination.  WHEEEE!!!!

Oookay. I visited an old haunt.... and acquired some questions asked of Animated Battlers from 2006 to 2012. Yes, I have a good collection of questions, though some are the same ones over and over.

Oh, I've begun working on the chapter that describes how to configure Animated Battlers. The new version has three separate configuration pages, and I have written MOST... of the first page. I'm trying to be a bit less technical in the explanations than the first help file I made. And I'm adding little 'Notes' to hep describe the ins and outs of what works, like how it doesn't make much difference whether you set battlers to default type or not... ccoa spritesheets override.

Could it ever be a real life experience of sorts?

Well, now I am glad to announce I have improved the mkxp fork I have been working one lately by increasing the custom resolution size to 800 * 608 or your favorite one. People that wanna compile it themselves can now enter the mkxpplus src directory and open the resolution.h header file to change the four values available there accordingly. For some curious reason, the maximum tiles for width and height need to be set like this:

actual maximum of tiles for window width + 1
actual maximum of tiles for window height + 1

Just divide the window width and height values by 32 (RGSS1, 2 and 3 maximum tile dimensions) and you will know how large that number actually is!

mkxpplus is freely available on github just as its parent project, Ancurio's mkxp also is. This means you got to compile it yourself or wait for us to come up with some precompiled binary executable file (.exe or .bin) you can use on your system. If you use Ubuntu or Kubuntu, you would be lucky as you would be able to get one in no time. I gotta see if I can cross compile one for Windows or get CMake working on it.

I must now add to my previous comment that I managed to run even RGSS3 or VX Ace games with mkxpplus on my box! I had to uninstalled (temporarily) some alternate version of the libjpeg8 library because some people dislike the changes made to it since version 7. They even ditched version 9 completely! Some alternative projects emerged as well like libjpeg-turbo or mozjpeg. Anyway it seems version 7 though 9 are more restrictive than 6b so it might still be required by many for years to come. I also noticed VX Ace scripts and its C++ backend were designed to center the images on screen, including windows. That wasn't bad for sure, even if it's nothing you couldn't change in XP as well if you save the changes in a custom Scripts.rxdata file.

I was having, err, fun playing my KChest ACE demo. Sadly, there's no Aluxes to laugh at there.

My help file for the Animated Battlers demo is currently very, very, very large. In fact, I know it's likely to be larger than half of the demos I intend to craft. But that stands to reason since this help file will include visual examples of various spritesheets and spritestrips, screenshots of incorrectly configured battlers, and more.

Still, I am more than halfway through the section that handles the system's configuration. The two chapters I am working on in tandem involve the Pose system and a discussion on Hash Arrays. Unfortunately, I'm at the point where both chapters discuss nested hash arrays. Oh, joy.

Oh
my
gawd...

I am now FINALLY done with the lengthy second page of the help file for this version of Animated Battlers. And with that, I am likewise done writing how one creates Hash Arrays and Nested Hashes... or at least down one level having one hash within another. I'm not too comfortable with the thought of covering a hash in a hash in yet another hash. I only want to go down the rabbit hole but so far.

Now I am working on the third and final page that discusses the configuration section, the section that covers battler movement across the screen. Compared to the first page, this one should be a bit easier until I get to the portion that handles individual frames for each battler's unique pose. Alas... more nested hashes.

Still, the help file is coming along nicely. And as I continue to go back and forth to compare settings, this endeavor also ensures the comments I left behind within the configuration pages are correct. And it's helped me trim a lot of dead material that was never necessary such the "Stationary Skills" array.