Golden Sun Camera Battle System

[DerVVulfman]

Ah, you meant that when you set the [0] in the actor's name, the camera did not rotate... not that he didn't move. I was kinda wondering what you meant. Yep, the [0] set the hero's camera rotation to zilch as it should have.

Now.... BE READY FOR A LECTURE.
(It took me 3 minutes to examine... and a bit more to write down.)


I see your issue with the system when you attempted to turn 'Random Angles' off. You did, in fact, properly set RAND_ATTACK and ATTACK values as you should have. The issue belongs to the 'camera_set' method within the Scene_Battle class. Or, more accordingly, the issue belongs to the code which he added into the 'make_battle_action_result' method that uses the 'camera_set' method.

The camera_set method receives two arguments, the camera angle value (val), and a random dispersion flag (disp). Obviously, the camera angle value is the flat rate value of the camera... 0, 90, 180, etc. The random dispersion flag is a true/false switch that sees if a little extra bump is added to the camera angle, giving a little randomness to the rotation. Normally, this value is 'false'. But if it is true, you get a little waver in the camera rotation. DO NOT EDIT OR TOUCH THIS METHOD. IT IS WORKING FINE!

It is within the 'make_basic_action_result' method where you would find your issue.

From lines 518 to 529 where you'll find an if...end[i] block that will change the actual camera angle. And within there, you'll find another [i]if...end block from lines 519 to 525. This inner block is the one that is controlled by the RAND_ATTACK switch. If the random attack switch is on, the system will run the 'camera_rand' method, otherwise it runs the 'camera_set' method... on line 524

Take a look at the 'camera_set' method on line 524. camera_set(GS::ATTACK, disp = true) Uh, oh! According to this, he set the random dispersion flag to 'true' so the battlers have a little extra randomness to their camera angles, even IF you have a fixed value angle! If you want that taken out, just set the line to read as: camera_set(GS::ATTACK). And there you go!

NOTE: You would also have the same issues with both skill and item flat rates, but the fix is the same by merely removing the disp = true code from the 'camera_set' calls. That would be on lines 548 for the RAND_SKILL system, and 572 for the RAND_ITEM system.

---

Also, this script may crash due to the dreaded F12 bug.... a situation where some scripts attempt to alias (re-attach/rename) code to methods already aliased. This results in what is called a stack error, a type of infinite loop issue.

For an example, run the program and begin a fight with one of the events. You don't need to go any farther than just entering the battlesystem itself. Hit the F12 key. Now with the system reset, go back to that event and start a battle again.

BOOM! Script 'RCBS Script' line 285: SystemStackError occured!!!

The 'screen_y' method was asked to re-include code and rename itself yet again (and would repeat for quite some time). The fix to this is easy. Look at the alias statement that reads thus:

Code:

alias rtmkd_camera_screen_y screen_y

Change the code to resemble this!

Code:

if @holylightstack_fix_screen_y.nil?
    alias rtmkd_camera_screen_y screen_y
    @holylightstack_fix_screen_y = true
  end

And guess what? THAT fixes the stack error with screen_y!!!

Now why does it work? When you first begin running your project, there is no actual data in the @holylightstack_fix_screen_y value. It is empty and nil. But when you run your game, it performs the alias and attaches your code, and then sets this (long) variable to a value of 'true'. This value remains set, even if you hit F12. So when you DO hit F12, it will see that this method already had run and won't attempt to attach new code again.

It has to be an instance variable (one with the @ in the name), so it will be retained when you hit F12.

Personally, I try to group up all my 'alias' calls in one group per class. Makes it easier to handle.