01-10-2012, 04:16 AM
Yeah, I knew you were gonna ask. Good thing I write pretty fast.
First off, I still have your SKILLNAME values stored in a Hash array. The can let you store things in the way I presented earlier. So, I won't go into detail there.
Second, I eliminated the whole Data_Manager module and Game_Skillpoints class from your code, and substituted it with code for the Game_Actor class. Since you wanted to (presumably) store points for each actor in your database and wanted it saved in your savegames, keeping it in Game_Actor was the logical choice.
Each time an actor is initialized, it resets the skillpoints, skillboost and etc. With that, it was just eaiser to add these values to Game_Actor and alias the initialize method. The very last thing to do was to add your modpoint and modboost methods into the class. Rather than use points = points + value, I just did a simpler points += value calculation. It does the same thing with less code.
Next, I tackled your WINDOWS code.
First, I added your Window_SkillComponents class. I don't see why you needed to set the opacity of this window, so I left it out. You didn't need them in the other Window classes either. But did you catch the bug I left in there? No? I also left out the 'refresh' call you put into the script. It's not saying 'Skills' in your window... Gotcha! Just put 'refresh' under the super statement, and it'll be fine.
Now about your Window_SkillFree. Can I assume this contains the free points you apply to a skill or something, and these are the points for a single given actor? I hope so, because that's what I thought it was.
First, I had to do a slight change to your initialize method. Rather than just a straight initialize call, I used:
This lets me use the data of a single actor in this window, in much the same manner you made your earlier modbonus methods. Besides the 'super' and 'refresh' calls in the initialize method, I also added @actor = actor as a statement. This lets the system use the @actor value throughout this single window class.
The display_free_points method in your Window_SkillFree class was changed to reflect this, as it no longer accessed $game_skillpoints.freepoints, but @actor.freepoints. It reads the freepoints value for this specific actor and now displays them in the format you devised.
Oh, and your refresh method? Nice. I particlularly like the way you recorded the font's size prior to changing it to something larger, and then resetting it back to the default.
The Window_SkillSelections class had to go through a few more changes than the others. Like Window_SkillFree, I changed your initialize method so it read data from the actor, and set up the @actor value so all data could be based off the actor in question.
Like other classes in the default system, I included a skill method. It just reads data stored in a @data value, based on the window's index position. In the item menu or the skill menu, it's actually data from the database, so a skill returned from the skill menu would read the whole name, icon, sp cost, and everything. Well, I figured you didn't need that. The data that THIS statement is returning is slightly different. I'll get to that later.
The refresh method in your class went through a change as I modeled it after the ones in the default menus. True... I didn't include a header, but I guess that could be added later. BUT... you may not want to have it in literally in a selectable window as it may screw up indexes. Could talk later about it. This current refresh method cycles through your list of skills much like your create_list method, but it only pushes the data into the @data array (necessary), After that, it determines the size of your list and stores it in the @item_max value (necessary too), performs the default 'create_contents' statement, and then finally draws every line by cycling through all the @data and running a 'draw_item' statement with each item.
Now I added two weird things. I added a whole new custom 'draw_item' method to this class, so I can have 4 fully formatted fields of data (name, points, boost, total) on each line while not having a required 'ICON' shown in the line. The default draw_item method draws an icon, and your data has none. The next thing I created was a customized version of the 'item_rect' method. While it can function as the default, it also lets me set the left-edge of the rectangle being drawn as well as a width to that rectangle. I used this to help me place the data where I wanted in each line.
OH!!!... Get rid of the 'skill_boost = 121 if item == 3' line. I used that just to make sure I had enough space between rectangles. My bad.
I bet you now wanna talk about the new Scene_CharSkills class, don't you?
Remember how I had to rework the initialize methods for your Window_SkillFree and Window_SkillSelections classes? Well, I had to create one for it here as well. But rather than passing the value of the actor from the database, you would need to pass the actor from the main menu. This means, you're passing the index of a party member.... regularly party member 0 to 3 (for a 4 party team). Like the others, I set it up so it has a default actor of '0' for the team leader.
Then, we come to your 'start' method. Mimicking other classes, I used the same super statement and the create_menu_background methods, followed by the statement that reads your actor index and find out which actual 'actor' from your database is being used. A little bit of editing was done by adding a viewport call, followed by your three 'Create_---_window' calls. But in each, I passed the @viewport value into these.
Your 'create_title_window' method was virtually untouched, other than the addition of setting the window's viewport to the one passed into its method.
The 'create_counter_window' method was edited more. Rather than just creating the Window_SkillFree window, I passed the data of the actor into the window with the following statement:
Now, the window just doesn't show data in that window, but data specific for that actor.
Following that, I set the viewport of the window like the previous one.
Hey! Guess what! The 'create_skill_window' was almost the exact same thing! I created a Window_SkillSelections window and passed the actor's data into it much the same way as I did with Window_SkillFree, and I set the viewport for the window. But after that, I told the window to set it's index position to 0... the very first line in your displayed data.
You didn't have anything in your 'terminate' method other than the super statement, so I added statements to displose of the background, skill, freepoints and selections windows.
I added a 'return_scene' method, but I didn't have it do anything. I just commented out a line that would shove you into menu position 1
The 'update' method is based on those in other classes and is pretty streamlined, though that's because I took out an if...else...end clause you'd normally find. It just updates the background, your windows, and then runs a method called 'update_skill_selection'. That's it.
And your 'update_skill_selection' is a new edition. It has a simple set of IF... statements. If the cancel buttons are pressed, play the cancel sound effect and run 'return_scene'... presumably exiting from the system But if the action buttons are pressed, it retrieves the skill data from your skill selection window, and then uses the 'p @skill' statment to print it.
The data being read is only the ID of the skill in your list. So it would return '5' if you click on the 'Scripting' category. You could very well have the 'p @skill' statement replaced by 'p Tenseiten::SKILLS::SKILLNAME[@skill]' if you wanted it to print the name of the skill.
First off, I still have your SKILLNAME values stored in a Hash array. The can let you store things in the way I presented earlier. So, I won't go into detail there.
Second, I eliminated the whole Data_Manager module and Game_Skillpoints class from your code, and substituted it with code for the Game_Actor class. Since you wanted to (presumably) store points for each actor in your database and wanted it saved in your savegames, keeping it in Game_Actor was the logical choice.
Each time an actor is initialized, it resets the skillpoints, skillboost and etc. With that, it was just eaiser to add these values to Game_Actor and alias the initialize method. The very last thing to do was to add your modpoint and modboost methods into the class. Rather than use points = points + value, I just did a simpler points += value calculation. It does the same thing with less code.
* * *
Next, I tackled your WINDOWS code.
First, I added your Window_SkillComponents class. I don't see why you needed to set the opacity of this window, so I left it out. You didn't need them in the other Window classes either. But did you catch the bug I left in there? No? I also left out the 'refresh' call you put into the script. It's not saying 'Skills' in your window... Gotcha! Just put 'refresh' under the super statement, and it'll be fine.
Now about your Window_SkillFree. Can I assume this contains the free points you apply to a skill or something, and these are the points for a single given actor? I hope so, because that's what I thought it was.
First, I had to do a slight change to your initialize method. Rather than just a straight initialize call, I used:
Code:
initialize(actor)
The display_free_points method in your Window_SkillFree class was changed to reflect this, as it no longer accessed $game_skillpoints.freepoints, but @actor.freepoints. It reads the freepoints value for this specific actor and now displays them in the format you devised.
Oh, and your refresh method? Nice. I particlularly like the way you recorded the font's size prior to changing it to something larger, and then resetting it back to the default.
The Window_SkillSelections class had to go through a few more changes than the others. Like Window_SkillFree, I changed your initialize method so it read data from the actor, and set up the @actor value so all data could be based off the actor in question.
Like other classes in the default system, I included a skill method. It just reads data stored in a @data value, based on the window's index position. In the item menu or the skill menu, it's actually data from the database, so a skill returned from the skill menu would read the whole name, icon, sp cost, and everything. Well, I figured you didn't need that. The data that THIS statement is returning is slightly different. I'll get to that later.
The refresh method in your class went through a change as I modeled it after the ones in the default menus. True... I didn't include a header, but I guess that could be added later. BUT... you may not want to have it in literally in a selectable window as it may screw up indexes. Could talk later about it. This current refresh method cycles through your list of skills much like your create_list method, but it only pushes the data into the @data array (necessary), After that, it determines the size of your list and stores it in the @item_max value (necessary too), performs the default 'create_contents' statement, and then finally draws every line by cycling through all the @data and running a 'draw_item' statement with each item.
Now I added two weird things. I added a whole new custom 'draw_item' method to this class, so I can have 4 fully formatted fields of data (name, points, boost, total) on each line while not having a required 'ICON' shown in the line. The default draw_item method draws an icon, and your data has none. The next thing I created was a customized version of the 'item_rect' method. While it can function as the default, it also lets me set the left-edge of the rectangle being drawn as well as a width to that rectangle. I used this to help me place the data where I wanted in each line.
OH!!!... Get rid of the 'skill_boost = 121 if item == 3' line. I used that just to make sure I had enough space between rectangles. My bad.
* * *
I bet you now wanna talk about the new Scene_CharSkills class, don't you?
Remember how I had to rework the initialize methods for your Window_SkillFree and Window_SkillSelections classes? Well, I had to create one for it here as well. But rather than passing the value of the actor from the database, you would need to pass the actor from the main menu. This means, you're passing the index of a party member.... regularly party member 0 to 3 (for a 4 party team). Like the others, I set it up so it has a default actor of '0' for the team leader.
Then, we come to your 'start' method. Mimicking other classes, I used the same super statement and the create_menu_background methods, followed by the statement that reads your actor index and find out which actual 'actor' from your database is being used. A little bit of editing was done by adding a viewport call, followed by your three 'Create_---_window' calls. But in each, I passed the @viewport value into these.
Your 'create_title_window' method was virtually untouched, other than the addition of setting the window's viewport to the one passed into its method.
The 'create_counter_window' method was edited more. Rather than just creating the Window_SkillFree window, I passed the data of the actor into the window with the following statement:
Code:
@counter_window = Window_SkillFree.new(@actor)
Following that, I set the viewport of the window like the previous one.
Hey! Guess what! The 'create_skill_window' was almost the exact same thing! I created a Window_SkillSelections window and passed the actor's data into it much the same way as I did with Window_SkillFree, and I set the viewport for the window. But after that, I told the window to set it's index position to 0... the very first line in your displayed data.
Code:
@skill_window.index = 0
You didn't have anything in your 'terminate' method other than the super statement, so I added statements to displose of the background, skill, freepoints and selections windows.
I added a 'return_scene' method, but I didn't have it do anything. I just commented out a line that would shove you into menu position 1
The 'update' method is based on those in other classes and is pretty streamlined, though that's because I took out an if...else...end clause you'd normally find. It just updates the background, your windows, and then runs a method called 'update_skill_selection'. That's it.
And your 'update_skill_selection' is a new edition. It has a simple set of IF... statements. If the cancel buttons are pressed, play the cancel sound effect and run 'return_scene'... presumably exiting from the system But if the action buttons are pressed, it retrieves the skill data from your skill selection window, and then uses the 'p @skill' statment to print it.
The data being read is only the ID of the skill in your list. So it would return '5' if you click on the 'Scripting' category. You could very well have the 'p @skill' statement replaced by 'p Tenseiten::SKILLS::SKILLNAME[@skill]' if you wanted it to print the name of the skill.