What's up, RMers?

[DerVVulfman]

Well, I just received my first bug report on the modularized scripts!  I knew there had to be something SOMEWHERE.

" But then nobody's perfect... almost nobody." - Lex Luthor in Superman © 1984 (Gene Hackman)

It was a simple oversight in the code that breaks down the massive [Control Variable] method in the Interpreter class.  I neglected to pass a 'value' parameter (yes, that's its name) into one of the method that TAKES the value and lets them be applied to game variables.  So if anyone had issues with variables... it should now be fixed.

That issue has since been corrected and the updated edition is found below:


  SDK Modulized 2.rar (Size: 923.39 KB / Downloads: 2)

But one repair doesn't mean its foolproof.  Somehow, somewhere, someone is making a better fool!   Continue testing anyway!

Meanwhile, the new edition went and sliced up more code, made some methods shorter, and added some new methods where the speed of animations and movement are processed.


  Why would one want to make small cuts where animation speed is processed?   All aboard the TRAIN of THOUGHT... CHOO CHOO!!!

Well, I came up with something kinda neat.   And I wanted it to be easily added as a script plugin without altering the existing base mechanics.  And that is a means to allow the animation and movement speed of field map sprites to remain (relatively) constant regardless of the frame rate that a game developer sets their system.

That is to say....  

• Under a normal game, your character moves normally at the 40fps.  
  
• Setting a game with the command "Graphics.frame_rate = 120", and your character will move like THE FLASH! 
  

The addendum script I concocted can re-adjust the character animation and movement speed BACK to practically normal!  It does this while allowing the actual processing speed to continue.   So all math and reactions can run at 120 and your characters move as normal.  STILL... it doesn't affect battle animations nor the speed of windows graphic fluctuations (the battle arrow flashes, the cursor rectangle, etc).

When I mentioned this achievement, I was sorta reminded by some that newer engines 'divide' the graphics engine that renders content as separate from the processing engine that handles the in-game logic.  Ergo, two separate speed values where one can set graphics to update at XXX while processing everything at YYY.  But my method works with the current mechanics of RPGMaker XP to VXAce.  

No, I didn't make any VX or VXAce editions though I could.

Still, I think what I have planned for release will be greatly appreciated.  And having a system to permita  generally static movement speed with our current engine will suffice until Son_Rukiri releases his alternative RPGMaker XP engine and Editor which indeed utilizes separate logic and framerate speed values:


His latest posting of the WIP here