[RESOLVED] RMVXace: Making my own status screen thing.

Started by Jragyn, August 15, 2015, 05:28:40 pm

Previous topic - Next topic

Jragyn

My goal:
 To create a status menu that fits the "16:9 ratio" thing(640x360 compared to the default 544x416).
 To allow the player to not just view the stats, but also view a brief snippet(help window) of what they do (ie: Attack- raises physical damage dealt).
 
My Progress:
 I am pretty nub with scripting. I meant to pick it up with RMXP, but then VX came out. Then work happened. Then VX Ace came out. More work happened, and MV is about to come out... but I already got started during the VX Ace era, so here we are. I put together modules that have some configurations in them (like vocab for the s/x params), modified a few methods that are supposed to enable higher-than-cap base parameters(they seem to work), and actually perform the minor adjustment for changing screen resolution from default to the ratio I mentioned before.
 I have a basic understanding of how it all works for the most part, and I feel like the issue I am stumbling most with is simply understanding the window to scene interactions, in addition to the details about things like command windows and how all that works. I've read over the default scripts again and again, and I just feel like I'm missing something. So I posted what I've got at the bottom. Currently, the script draws all the parameters, and I tried to do things with the Scene_Status and making it do the selectable thing... but its definitely not working.

I was hoping I could get a peer review or something from one of the experts(read: more knowledgeable than I am) and maybe a shove in the right direction with wisdom about how the things I'm tripping over work. :( Sorry for the mouthful, just trying to be as clear as possible.

1. What RPG Maker you are using?
   -RMVXace
2. What exactly is the problem you are encountering? Which scripts are you using?
   -It is a naked project, the only thing I'm using is my own script (listed below).
3. In which environment does the problem occur?
   -The issues start occurring when I decide to start going into the menu and pressing buttons.
   -As written and pasted on Pastebin, it is setup so that if you choose any of the selections on the status menu, you get:
"Script 'Window_Base' line 72: RGSSError occured. disposed window." Which I'm sure is because I failed at doing the right thing with window creation.

For clarity, I've done my best to comment what I believe its supposed to do or at least what my intent was for the code listed below:
And also, so I don't have a mile long post, I shoved it onto pastebin:

Click here for the module for the Revamp.
Click here for the Revamp on Pastebin.

Single instruction: Module goes in its own script section above the Revamp itself.

And thanks again for anyone who lends help, I appreciate it.
A bright light can either illuminate or blind, but how will you know which until you open your eyes?

KK20

Your Window_Param_Details doesn't call Window#initialize. You need to include a "super" key-word in your initialize method in order to combat this.

The reason for the error is that the attribute "contents" is created in Window#initialize. Without calling that, your window is classified as disposed or non-existent. Take a look at the other window classes and you will see that they call "super" in their initialize methods.

After doing that change, it only produced 3 empty windows so I have no idea where you're going with that.

Other Projects
RPG Maker XP Ace  Upgrade RMXP to RMVXA performance!
XPA Tilemap  Tilemap rewrite with many features, including custom resolution!

Nintendo Switch Friend Code: 8310-1917-5318
Discord: KK20 Tyler#8901

Join the CP Discord Server!

Jragyn

 :^_^':

What I have done thus far is just me tinkering around trying to figure it out, but I'm no programmer(yet! Going to school for it this fall).

When I adjust this as you suggest by adding
super

It throws an error regarding wrong number of arguments (5 for 2).
I recall getting this error before, and my solution was to eliminate the super because I was hoping to pass in more stuff upon window creation so that the window generated the contents I wanted it to... maybe I'm going about it wrong?

Spoiler: ShowHide

class Window_Param_Details < Window_Command #Selectable?
  def initialize(x, y, width = 128, height, key)
    super
    @key = key
  end#def
 
  def make_command_list
    case @key
      when :paramb; write_b_commands
      when :params; write_s_commands
      when :paramx; write_x_commands
    end
  end#def
 
  def actor=(actor)
    return if @actor == actor
    @actor = actor
    refresh
  end#def

the idea behind adding more things to pass along with creation was so that each window when drawn would draw the proper list of parameters.

Do you think there is possibly a more efficient way to go about this that I can learn from you? Like I said before, this is pretty new to me.

Winded and lengthy Explanation:
I started this personal project just as a remodel of the status screen to display all the parameters, including the ones that are normally hidden (like EVA/HRG/etc). Then I realized that the player/developer may not fully understand what they do, so I figured why not include a help window to display this information? I wasn't sure how I could do this, but I know that when you are in the equip/item/skill menus, you can use cursors to hover over items in a list to fill the help window with stuff (typed by the developer of the game in the database). So I tried to make a single, giant list, 3 across by 10 vertically... but I didn't know how to do that, so I figured that making three separate windows each containing a list of the parameters would do the trick. With delicate positioning, I could put it ontop of the existing full-screen status window w/ .opacity=0, and it will hopefully just... work.

A bright light can either illuminate or blind, but how will you know which until you open your eyes?

KK20

Had fun with it and decided to just partially finish the missing stuff:
http://pastebin.com/aPDcMWMU
http://pastebin.com/THvDs1Xr

First thing to notice is that I removed your 3 windows idea (i.e. removed Window_Param_Details) and just worked with the Window_Parameter_Choice to make it individually select each parameter. Also added a new method to the Vocab module that will serve to display the parameters' help text. Did some minor repositioning and cleaned up the scene code.


The keyword super means to call the superclass' method of the same name. In your case, Window_Param_Details was a subclass of Window_Command (its superclass). Using super in Window_Param_Details#initialize method will call Window_Command#initialize method.

If you do not pass any parameters to the super, Ruby will assume you are just passing ALL the parameters for the current method. Window_Param_Details#initialize takes in 5 parameters: x, y, width, height, and key. So by only putting super by itself, it will essentially try to call
Window_Command.new(x, y, width, height, key)

But if you look at Window_Command#initialize, it only takes two parameters: x, y.

class Window_Command < Window_Selectable
  #--------------------------------------------------------------------------
  # * Object Initialization
  #--------------------------------------------------------------------------
  def initialize(x, y)

Which explains the error you received: you were passing in 5 arguments when the method only accepts 2.

To fix this, you were supposed to do this in Window_Param_Details#initialize
super(x, y)

Now this will effectively call
Window_Command.new(x, y)

and cause no more problems.

Other Projects
RPG Maker XP Ace  Upgrade RMXP to RMVXA performance!
XPA Tilemap  Tilemap rewrite with many features, including custom resolution!

Nintendo Switch Friend Code: 8310-1917-5318
Discord: KK20 Tyler#8901

Join the CP Discord Server!

Jragyn

What you did was effectively what my original goal was, but I had no idea how to accomplish it: To put it all in one window and just make it wrap... but I ran into the issue where the first set of parameters(base) were lesser in number than the other two sets (s and x). I'm trying to look over what you wrote and understand it; it appears that you accomplished it by modifying the cursor movement methods? And the help text, you did this by index instead of by the specific parameter? Is this correct? And then, you made my Scene_Status look a million times more clean than I did myself, haha. If I had to guess, what you wrote in and fixed looks almost exactly like default scripts in their cleanliness.

I sort of understand what you did, and it makes a lot more sense as far as efficiency is concerned... but via the methods I was using, is my goal accomplishable? I'm beginning to question that now that I've seen success via a much easier route...

A bright light can either illuminate or blind, but how will you know which until you open your eyes?

KK20

So what I did was I used your Window_Parameter_Choice class that, at first, didn't seem like it really did anything. All of the parameters are being drawn directly onto Window_Status as you had it before. Window_Parameter_Choice acts as like a...dummy window of sorts. If you look at it closely, you'll see that Window_Parameter_Choice has absolutely nothing drawn to, is completely invisible except for the selection cursor, and stores no data or items. All it knows is that it contains 30 items in 3 columns and 10 rows.

The trick of it all is to position Window_Parameter_Choice over Window_Status so that the cursor lines up perfectly over each of the parameters. If we were to try and make Window_Parameter_Choice function like Window_ItemList for example, we would have difficulty with displaying the base stats as you mentioned. We would have to rewrite the item drawing method to compensate for those 2 missing stats.

But the biggest problem would be the cursor itself. There is no built-in functionality to tell Window_Command "don't highlight items #24 and #27" and still operate normally. So I modified the cursor_down/left/right methods in Window_Parameter_Choice: it checks if the cursor is currently at an index that would move it to the empty spot should the player press in that direction.

 #--------------------------------------------------------------------------
 # * Move Cursor Down
 #--------------------------------------------------------------------------
 def cursor_down(wrap = false)
   if index == 21
     return
   else
     super(wrap)
   end
 end
 #--------------------------------------------------------------------------
 # * Move Cursor Right
 #--------------------------------------------------------------------------
 def cursor_right(wrap = false)
   if index == 26 || index == 23
     select(index == 23 ? 25 : 28)
   else
     super(wrap)
   end
 end
 #--------------------------------------------------------------------------
 # * Move Cursor Left
 #--------------------------------------------------------------------------
 def cursor_left(wrap = false)
   if index == 28 || index == 25
     select(index == 25 ? 23 : 26)
   else
     super(wrap)
   end
 end

So looking at cursor_down, you can see that if the cursor is at index 21 and the player presses down, we deny the cursor from moving at all using a return.
Here's an image that should explain the index positions:


As for the help text, it did it based on the cursor's index position. So you can see that when the cursor is a 0, it's selecting the MaxHP parameter. When at 1, TGR. And so on...
Because Window_Parameter_Choice has no knowledge of the parameters themselves (as I explained above), the only thing I can pass to the Vocab method is the cursor's index.

I'm not sure by what you mean with "is your goal accomplishable" because I thought I basically did that for you. :P The script could probably be written more efficiently but it's not like it is performance heavy where a small algorithm change makes it a million times better. What you have is a good start.

Other Projects
RPG Maker XP Ace  Upgrade RMXP to RMVXA performance!
XPA Tilemap  Tilemap rewrite with many features, including custom resolution!

Nintendo Switch Friend Code: 8310-1917-5318
Discord: KK20 Tyler#8901

Join the CP Discord Server!

Jragyn

After seeing the explanation of what you did, as you stated you did accomplish what I was attempting to do, with finesse even, haha. Because you lined up the rectangle around each of the parameters so well(something I failed to do as witnessed with my original version), I thought maybe you found a way to write the values into each index instead. Either way, I really appreciate you explaining all that, and the picture. It was quite clear, and was written in a way I could understand it.

Looking at it, and reading over your explanation, do you think it would've been easier/better to use the invisible Window_Parameter_Choice and just write in the parameters that way? I had considered trying that later down the road, but I figured I would try my best to come up with core functionality first(which you did), and attempt to optimize it later.

Hmm. Thank you again, mysterious stranger KK20. I don't really have anyone I can talk to directly about this stuff, so I appreciate again that you broke it all down for me. As I work on this further (and hopefully flesh it out into a full CMS or something), I'll be sure to come back here for perhaps more pearls of wisdom from you.  :haha:
A bright light can either illuminate or blind, but how will you know which until you open your eyes?

KK20

There really is no sense of writing the parameters into another window if, in the end, the status window appears to be ONE BIG window. If your status scene were broken up to have, for example, the player's HP/MP/EXP bars and face in one window, the equips in another, and the help text in another, then yes, it would be better to have your parameters drawn in Window_Parameter_Choice.

Plus I think it would complicate things a bit too much. Window_Selectable is written to assume that all of its children will function in mostly the same way, which is to take in an array of items and iterate through each of them one by one to draw them to the window in a specific order. Had you placed two more stats underneath LUK, then, with some modifications, you might be able to get away with it.

You would also need to pass in an actor parameter to the window's instantiation and keep track of when the actor changes. In the end of things, you probably would have to write more code than what you have now.

Glad to be of assistance. It's fun teaching scripting to others whenever I get the chance ~

Other Projects
RPG Maker XP Ace  Upgrade RMXP to RMVXA performance!
XPA Tilemap  Tilemap rewrite with many features, including custom resolution!

Nintendo Switch Friend Code: 8310-1917-5318
Discord: KK20 Tyler#8901

Join the CP Discord Server!

Jragyn

Hah, I wanted to try and make it round(the three columns of parameters), but I just couldn't come up with a divisible-by-3 number to split the parameters into three columns, so I left it as-is.

With all of what this status window does, I am certain I can clean it up and fill in all the details for what parameters do, etc. and then move onto something else like perhaps the equip menu, since now that there are so many parameters, it should also be updated to reflect this!

I look forward to seeing what else I can pry from your experience when it comes to RGSS3/Ruby. Thanks again!  :haha:
A bright light can either illuminate or blind, but how will you know which until you open your eyes?