What's up, RMers?

[BeJeremiah]

I am not great at ruby but I like to play around. Latest project. Skill Grid like Chrono Cross (Well, as close as possible).


  element-equip-01.png (Size: 71.73 KB / Downloads: 4)
  element-equip-02.png (Size: 97.37 KB / Downloads: 3)

[kyonides]

Well, I was visiting another forum and found that an admin there posted his own chest script about two months ago. I checked out one of his so called followers' reactions and found it ridiculous to read that he thought there was no need to event chests anymore. I had posted KChest XP, VX & ACE since 2016 on every single forum I usually visit and that guy did not even double check there was a better chest script that look much better than that crappy looking script he was praising there? I guess there are people that have a bad taste for scripts :P

After working on KyoGemBoost XP fixes and Klearance XP, VX & ACE improvements, involving the inclusion of other scripts like GiveAway and KChest, and Klearance main feature, the honeycomb pattern pass code, I feel like I'm out of brilliant ideas once again. I hate that!

[kyonides]

Developing strange scripts is fine but I wonder if there's any good guide telling one how to make useful dll's or so files for RPG Maker plus other Ruby related stuff. I would really like to go beyond pure Ruby and compile a couple of useful libraries in C as well.

[kyonides]

I had to fix a few things in KyoGemBoost XP and VX, but I have not uploaded the new demos with the updated scripts. I have been working on the ACE port as well, but stuff changed a lot for sure. For starters, a hero does not have some hp method but a param(0) class method instead, there is no hpmax or maxhp but a param_max(0) method, there is no hp_plus one but a param_plus(0) method... Fortunately the gems are now calculated as part of the param_plus calculation.

Since ACE ported all basic stats to the hero's current class, the hero won't keep its hp or mp if he changes his class. Nonetheless, my gemstone attributes like extra hp or mp won't get lost unless you remove the gemstones.

[DerVVulfman]

I have some catching up to do with some of my scripts. You may nave noticed that I worked on fixing up the Vehicles script thanks to a bug report made this past November (though I was busy on a script request at the time). And I also worked upon my old Limit Break script which I haven't touched since the forum was renamed Save-Point. They need some changes, whether alteration in script layout, changes in naming conventions, or overhauls of some key systems. Now I am working on another script that is long overdue for a touch-up.

I inherited the Animated Battlers system from the original creator, Minkoff. And the last version I worked upon was back in 2012. Most of the time I worked on it was really back in the 2007-2008 era when scripting was less uniform. And while I had programmed things before, I was not wholly inexperienced with Ruby. Every instance of someone asking me to add some new feature was just me merely pasting in new routines into the existing code.... sloppily.

Oh, Minkoff told me it was funny that I kept his name on the script.

So now I am taking a hard look at the system and considering plenty of changes. Obviously, the configuration system needs to be PROPERLY put into a configuration module all its own, not just a separate page. The script call to turn on/off the sideview mirror system must not be handled by a global variable, a method that is deemed sloppy by many standards. And I am breaking up the extremely lenghy methods within the Sprite sections into smaller and more manageable code. This I have already begun, and found a bit of code that was redundant... but only a bit.

But I do have to take care. Some scripts that I am familiar do require some special methods I have in Animated Battlers for detection or camera angle purposes. So I certainly need to be careful in what I am doing to ensure the same level of combatiblity as I had before.

[kyonides]

I have been working on my own crafting script, I have finished the recipe template and the parser section of the script, but I have no freaking idea of how to design the GUI...

Anyway it will be a shop based system instead of a recipe list. Even so I pretend to let the player add a few recipes to a local workshop. I am unsure if I should include a GiveAway script binding there, you know, I am kind of lazy. :)0

[DerVVulfman]

I've been busy working on reconstructing Animated Battlers with a new configuration system.

The way I am handling all the individual pose and frame systems will be more uniform.  In this, every feature is going to be keyed (or identified) by the actor or enemy ID itself.  For example, I used to have an advanced poses system keyed by the individual skills, but was broken down by each actor.  It looked sorta like this:

Code:

 # Set Skill 61 to use pose 6
 MNK_POSES_CASTED     = {61 => 6}
 # Set Skill 61:  Actor #2 uses pose 4, Actor #3 uses pose 5
 MNK_POSES_CASTED_A   = {61 => {{2 =>4}, {3 => 5}}, 62 => {{2 => 5}}  }  

    This is a MESS!!!


But the new idea is that every pose or frame in the system is based on the actor or enemy ID, and then may branch off to the skills instead.  Below is a variation I am considering:

Code:

 P_CASTED[2]          = [ [61,4], [62,5], [63,4], [64,8] ]      

 

This is a lot cleaner and is specific to actor #2.  Here, we can see all four skills he gets (from 61-64) which he receives by default as he levels, and shows the pose each receives in a  [Skill, Pose ] combination.

The fun part is to ensure I don't 'BREAK' stuff.  I mean, Animated Battlers works already.

Oh, and the prime routine that grabs the correct pose value has now been cut down to just 1/3rd of its size due to the new standards I'm employing.  I just wish I could trim the rest down by that much.

[Siletrea]

I've been busy working on reconstructing Animated Battlers with a new configuration system.

The way I am handling all the individual pose and frame systems will be more uniform.  In this, every feature is going to be keyed (or identified) by the actor or enemy ID itself.  For example, I used to have an advanced poses system keyed by the individual skills, but was broken down by each actor.  It looked sorta like this:

Code:

 # Set Skill 61 to use pose 6
 MNK_POSES_CASTED     = {61 => 6}
 # Set Skill 61:  Actor #2 uses pose 4, Actor #3 uses pose 5
 MNK_POSES_CASTED_A   = {61 => {{2 =>4}, {3 => 5}}, 62 => {{2 => 5}}  }  

    This is a MESS!!!


But the new idea is that every pose or frame in the system is based on the actor or enemy ID, and then may branch off to the skills instead.  Below is a variation I am considering:

Code:

 P_CASTED[2]          = [ [61,4], [62,5], [63,4], [64,8] ]      

 

This is a lot cleaner and is specific to actor #2.  Here, we can see all four skills he gets (from 61-64) which he receives by default as he levels, and shows the pose each receives in a  [Skill, Pose ] combination.

The fun part is to ensure I don't 'BREAK' stuff.  I mean, Animated Battlers works already.

Oh, and the prime routine that grabs the correct pose value has now been cut down to just 1/3rd of its size due to the new standards I'm employing.  I just wish I could trim the rest down by that much.

this looks awesome! can't wait to see it in action!

[kyonides]

Well, I finished the ACE port of KyoGemBoost, I also had to change a script call in XP and VX versions because it was too large... I also had to fix a couple of things in all versions of my script. The lamest part of porting it to Ace was the way the command and gem list windows behave by default that did not match my requirements so to say, they look modular but also convoluted. Anyway, I have already uploaded a demo for all VX Ace forumers to play with.

What if 2 heroes are able to cast the same skill, wulfo?

[DerVVulfman]

Code:

P_CASTED[2]          = [ [61,4], [62,5], [63,4], [64,8] ]  
P_CASTED[3]          = [ [61,3], [63,7] ]  
P_CASTED[-2]         = [ [62,4] ]

Here, I have Basil as before. When he casts Skill #62, he uses the 5th pose... and the 8th pose when he uses Skill #64.
But Cyril (Actor 3) can cast skill 61 using Pose #3, and uses Pose #7 on skill 63.
Now we have a 'negative' ID here for the third example. Negative IDs are enemies, since they're essentially negative to the party. And this one is Enemy #2 in your database (the Sagahin).