What's up, RMers?

[DerVVulfman]

WOOHOO... The preliminary tests with the TRICKSTER battle-systems is DONE. After all I've done with Animated Battlers prior to this stage, nothing needed to be altered! His ATB system is working sweet as long as you turn one of the switches controlling delayed action on. The Turned-Based systems all work fine. Of the systems, only his TRTAB system can be buggy as hell because he made no allowances to pause for battler actions. I did have a switch in Animated Battlers to help with this, but it only goes so far.

Did I mention that the attackers rush forward to where their target is on the map... and not where they're placed at the start? This means that a ghost might be running to Aluxes to attack him while Gloria runs straight up and WHAPS the ghost with her Rod before the ghost can retreat! Yeah, I forgot to mention that, didn't I?

Well, the STEP FORWARD feature is now in the works. And of the working systems, it is functional with both the RTAB system by Cogwheel and my own Skill Delay system for the default battle-system. It was a struggle to discern what was needed between the two systems, and how to force the battler to step forward at the required time, or not to step forward as the case may be. I did have to modify my setmove function to include a new condition, one I felt was definitely necessary.

Odd though. I encountered a (shh... it's not a bug.... call it ) ... NEW DESIGN FEATURE! YEAH, THAT'S WHAT IT IS!!!

*COUGH* Yeah. If the final blow comes from a battler who used the 'STEP FORWARD' chant system, it negates the Victory Poses altogether. Not cool, man. Not cool. So that's something I need to track down.

But later. I have a number of battle-systems to test with Animated Battlers' new feature. Charlie Fleed's CTB is gonna be a bit interesting to work with as his is built straight into the main system. Sure, that could be the same Insofar as Trickster's collection, but do one and you do them all. All of his battle-systems use completely identical methods and values to control skill delays. Of course I'd have one last system to mention, and that would belong to ParaDog for the skill delay script he crafted, the "ATB Option - Spell Delay".

Still wondering if anyone has thoughts about a replacement name for the system.........

[kyonides]

Once wulfo said something about desperately needing some soundfont for any project requiring the fluidsynth library. Well, the mkxp developer already provided a link to an open soundfont sf2 file!

https://www.dropbox.com/s/qxdvoxxcexsvn4...x.sf2?dl=0

[DerVVulfman]

Odd though.  I encountered a  (shh... it's not a bug.... call it ) ... NEW DESIGN FEATURE!  YEAH, THAT'S WHAT IT IS!!!

*COUGH*  Yeah.   If the final blow comes from a battler who used the 'STEP FORWARD' chant system, it negates the Victory Poses altogether.  Not cool, man.   Not cool.  So that's something I need to track down.

DISCOVERY!!!! The issue wasn't only regarding the step-forward system, but the system that moves the battlers across the screen.

ANALYSIS:
As an animated side-view system, battlers run across the screen and perform some manner of animation pose. And when the battle-system checks to see if all the enemies or allies are done with (dead or escaped), It runs the victory pose. This is expected. However, the system that executes the victory pose is ignored if one or more battlers is still running across the screen performing this other pose.

SOLUTION:
Victory Pose systems are placed within the 'start_phase5' method of the battle-system, a section that is accessed only through the 'judge' method itself. That makes it EASY to fix. The judge method is executed in the update method, so it is checked over and over. So what I did was include a special check to see if any battlers are moving across the screen. If any are moving, the judge method is exited.

Woot... now all victory poses work, even if the battlers were moving after landing the final killing blow!

[kyonides]

I didn't even have time to play test a game script like EkuipSkills XP, I have been busy dealing with mkxp compilation issues. It's a good executable replacement for the RGSS based makers in my humble opinion, still, it has a kind of steep curve of learning when we're talking about compiling it all by yourself. Of course I wasn't alone, but it seemed I was most of the time. I had to cheat in order to make the make app understand it had to find the required modules. Curiously not all of them were installed previously as I first thought. I also was told to install over 80 MB of Linux libraries because it was ignoring my boost library. I used my own criterion and found out I only needed to add one more library to my package manager which meaning it would be available systemwide.

My main goal was to use state of the art libraries to prolong my pet executable's life as much as possible, and it seems to be a success so far. I updated boost, free type, a few others, and even Ruby itself! It now features Ruby version 2.5!! It does support MIDI playback for sure. Fast is mkxp's middle name.

There's a catch! There always is such a thing... I might have made a mistake somewhere because it only plays MIDI but no OGG nor MP3... Yeah crappy as hell! Even so I knew I should use a SDL_sound fork that I didn't really implemented before I ran cmake and make respectively. I guess it can be fixed at some point.

No failure would change the fact there are prebuilt executables and library files so my partially buggy binary file won't make your Linux OS crash at all. One of the reasons I wanted to use these open source port was to implement snapshot taking in any ported RMXP game. A fellow Windows mkxp enthusiast seems to have encountered some soeite bugs for disabling some control structure that were enforcing a division among RGSS versions placed there for a means of supporting slightly different string access methods required by version 1 and 3. Some Sprite stuff also experienced shadow and outline glitches there...

Keep in mind there are prebuilt binary executables that don't share the same fate as our custom versions of mkxp.

[DerVVulfman]

SUCCESS AND STUPIDITY can go hand in hand.

For some time, I've been working on adding a new feature for Animated Battlers. This feature has the battler take a step forward before he or she begins chanting a spell in which to use. This being different than the normal 'waves your hands' and THEN steps forward system as most are opt to use... because it is a hella lot easier to create.

I made immediate headway with this option with Cogwheel's RTAB system and his own Skill Delay system. However, the one that I wrote for the default battle-system was giving me issues. However, I made headway and have now tackled the hurdle of having the 'Casting-Step' option become cross-platform among battle-systems. But as I did succeed in making Animated Battlers recognize and work with my own Skill Delay script, it generated an odd error where any leftover casting might trigger an error.......

Assume you have a ghost being attacked by two FIRE-casting mages, and FIRE is a delayed skill. If the first fireball volley hits the ghost and kills it, the second fire volley may still be in the battle-system queue... and trigger an issue with a skill being applied to a NULL enemy (stage4_phase2), or the skill gets cast immediately by the mage the moment a new battle ensues. Both of these scenarios had to be handled if encountered... and now are. So... Skill Delay is getting upgraded too.

So now, after ensuring it works with these two battle-systems, I am now proceeding to have the Casting-Step' option work with ParaDog's system.

As to the stupidity... Remind me that ParaDog's skill delay system requires that I ADD A STUPID 'STATUS EFFECT' TO THE DATABASE FOR IT TO WORK!!!!!! I was going crazy trying to figure out what the hell I did wrong and why skills were not working.... *SIGH* I had to take a sabbatical and kill off about a dozen assassins in an Elder Scrolls campaign before it dawned on me that I was a moron. Skills and rudimentary skill delays are now working. I just gotta make them step forward properly now.

[DerVVulfman]

CELEBRATION TIME IS COMING!

Animated Battlers has now passed the Paradog and Charlie Fleed stages of development! Both of these systems with their skill delay options (built-in or optional) now allows the use of the 'Step-Chant' system without a hitch. Well, okay. There's a hitch. But I'm talking to Charlie about it.

So the last phase of inserting the 'Step-Chant' feature is to run the system against all of the Trickster-written battle-systems... and that's a good five battle-systems in all. I have already begun work on it, and the character performing the chant does step forward before he/she begins waving his/her arms.

Two odd points to handle with the current Trickster system so far: One is that the caster may nor perform the actual 'pose' of them waiving their hands. The other is that a delayed skill that kills the last enemy might not end battle but require you to choose an action (Attack/Defend/Skill...) first instead. Granted, once you make the selection, battle will end.... but it's annoying.

But for now.... HAMBURGERS!!! I'm taking a break.

Hey, anyone got a new name in mind for this version? Its structure is definitely different than the original....

[kyonides]

Well, mkxp compiling process has ended successfully providing me of a working binary executable I can run on my flavor of Linux. It plays all the supported audio files, it displays images, it lets me pick stuff, I can test custom scripts as well. Everything is running smoothly. Even so there is always a need to get more from it so I disabled some control structures to let me access VXAce's features as well even if I'm running some XP based game!

Yeah I get stuff like Graphics.snap_to_bitmap for starters. The outline might not look as good as in Ace, but it can be disabled if needed via script call. Higher resolutions might be tricky in its current (practically default) state. It might need to get some tweaking before it lets you get a large map on screen instead of a rectangle of 640x480 only...

Edit

After applying a so called patch to mkxp tonight, these are the end results of changing the screen resolution to 800*608, not involving any changes in default scripts except for a few labels I added, he, he.

[kyonides]

Well, I had found a strange glitch that occurred whenever you placed windows under the 480 px height threshold...



Yeah, I couldn't explain why the corresponding text would just vanish in makerish thin air at all. No sprites were afflicted by this buggy illness at all! How weird! It made my increased change resolution patch crappy at best. Later on I did find a solution, just take a look at the new samples I've collected for you all to get amazed at mkxp's useful capabilites thanks to OpenGL!



And yes, it's running on Ruby 2.5.1!

Please ignore this links for they will only lead you to the screenshots I posted above.

https://i.postimg.cc/63SVNx7M/mkxpkyonid...800fix.jpg
https://i.postimg.cc/mkHYLpCB/mkxpkyonid...800fix.jpg

I forgot to mention I created a github "fork" of mkxp featuring its increased screen resolution. Ancurio, the original developer, is openly against adding such features. When he finds it convenient, he treats mkxp as an engine or an emulator. (Only because he doesn't want to keep working on his project... And you call me lazy! )

[kyonides]

People and furry audience, I come tonight to let you know I will be able to make a custom database for my rm and mkxp and Gosu games. I recently managed to compile a Qt5 MainWindow that lets me add lists of items or whatever I wanna keep there. Obviously other stuff like spin boxes, descriptions, AP, breakable or cursed weapons and much more is now possible to compile it. My window would be able to run on Linux and Windows due to Qt5 framework's portability. Of course it wouldn't be that great if I couldn't embed Ruby 2.5 there, but guess what! I managed to embed it and even create a CRuby module named Test and print its Ruby class name!

Years ago I manage to do it via qtbindings rubygems but it was a bit slow for my taste. This time I will get a higher speed execution and a freely modifiable database. I am one step closer to making a free mkxp implementation of RPG games! (Yeah, Gosu also gets lots of benefits here!)

[DerVVulfman]

SUCCESS!!!!


Though with an expected case of one jerk making waves..... 

I have just run tests through every battle-system that my Animated Battlers supports.  And of those that include an option for a delayed skill effect, only one specific battle-system decided to cause trouble.  That one battle-system is Trickster's TRTAB system.  It had the most rewrites of battle-system code for an RMXP SDK script, so it was expected.   So I placed a very simple statement within the system that blocks the forward-stepping option from being triggered if Trickster's TRTAB is detected.  Personally, I think Trickster's ATB script works just fine.

For those that have used Animated Battlers but are only catching up, the new 'step-forward' option I am discussing is something that works with skill-delay options.  This new option allows battlers to step forward out of formation when they are told they are casting a skill so they can wave their arms like crazy when chanting a skill.  Once the delay is over with, they cast the skill itself and then return to formation.  This is different than the other option where they merely stay in formation while chanting, step forward, throw the spell, and return.  This new option is ONLY for skills, as it would look out of place for 'Attack' or 'item' options.

There is still some script cleaning to perform.  I added a couple more methods and aliases to accommodate all the battle-systems.  But that's nothing.  For naming conventions, I am changing the names of variables that include Minkoff's name (ie mnk_) to use a more current style.  And I am going to have to decide on the true and final name for the configuration module.  After that, I'm going to record every method within the system for a totally rewritten Help File.  Let's face it, the old help file SUCKS!!!!!