I'm on the process of reworking the interface for my game, and I already anticipate I'll most likely need a new windowskin altogether.
as it is right now, it has a few modifications like gradients and recolors, but I mean to design an entirely new one... the problem is, I can't find anything about how the program cuts down the windowskin file *into* an actual window.
was it ever tried, to rewrite those functions? by anyone?
I could probably bypass them and build a new Window class on my own (it's just the background that I need to change), but if I could just hack them and modify them without rebuilding them completely, that'd save me some time.
I looked through MV's functions, and it does have the step-by-step build I was looking for, but when I tried to find those methods in Ace, no luck.
EDIT:
Window Replacement is out.
https://forums.rpgmakerweb.com/index.php?threads/window-object-replacement.99447/
any bug reports, questions or related, will be addressed there.
Window, Window_Base and windowskin calls
● ARCHIVED · READ-ONLY
-
-
'Scripts' is where people who have written a script they want to share with the community can post it.
[move]RGSS3 Script Requests[/move] -
I thought I was posting on the help forum.... oh well...
I'm not asking for a script initially, only for a language reference, but if someone has or can make a function to manage that, I'll take it. -
*bump*
anyone?
any of the experienced coders ever tried anything like it? -
That is all handled by the window class. Its not located in the scripts but rather its hidden. You can learn more about it in the built in help section but it only gives you very breif overview. It does not show what you are looking for i believe but it might help you achieve what you need.
-
Rewriting a new window class would be very, very time consuming. I don't mean time consuming on writing the code itself while you can interpret it that way, but my guess is the built-in window class is already optimized on many things that it doesn't drop the fps. Technically, you can try to create your own window class by using multiple sprites packed together, but that will be a massive fps drops.
And as Vindaca said, it's hidden (that I believe it is) within the .dll
as for @Kes I believe it suits best on learning ruby and rgssx forum -
[move]Learning Ruby and RGSSx[/move]
Is it that you just want to change the windowskin part way through the game? If so, I have a way of doing that. -
what I want is to know which sprites are used to build the border and the background.
I know *how* to do it, I just don't know *how the original code* does it.
if I know how it's done in the original, I can overwrite those functions and leave everything else as is.
I could potentially disable the call to Window, and write down which functions are called up, and then try to mimic how they work, as they fail.
EDIT: I just realized that MOST of what I need, is in the help files, but I'll still have to figure out the cursor update, some proportions and whatever pops up.
I just placed the Window stand-in, and *tracking it as it fails* is possible.
..... let's see how it turns out. -
The way u said was more like "Ok, so I want to change how windowskin template works, now how to overwrite window class?", now you said you only want to know which sprite that handle border, contents, etc.
And by the cursor, do you mean the flashing boxes when you select a menu? -
no, I don't want to overwrite it completely, just the way it puts itself together; I still need it to update and trigger as usual.
but in order to do that, I need to know *how* it *puts itself together*.
once I figure that out, I can replace those values with the dimensions for a new window skin, and everything down the line will adjust accordingly.
I still have the demo of MV which has the base code, and *it* has a Window object broken down.
I'm trying to reverse-reverse-engineer (?) that Window into an Ace version XD -
The windowskin is split up and reasembled using rect on the original sprite and drawing it out accordingly. Honestly it seems like what you are trying to do can be done easier then how you are trying to occomplish this.
The window class can be called to create any size window you want. The only reason i could see you wanting to rewrite anything is if you are trying to create an irregular shape.
If you are trying to do something a little more specific you can always get rid of the window skin.(easiest way is to replace the original with a blank dummy) then create a custom img and use it as a bg image for your menu. There are also scripts that allow you to change the cursor i believe.
A good place to learn how to bulid a window is the menu base and menu window classes. If you can follow along you can get a good idea how to write one.
Do you have any experience with ruby? I see that you mention mv and ace both. They are very different when it comes to code. -
self taught.Do you have any experience with ruby?
calls to variables and control structures are still calls to variables and control structures.I see that you mention mv and ace both. They are very different when it comes to code.
I can tell apart a conditional from a loop...... a conditional is always a conditional, and a loop is always a loop regardless of language!
I don't study language,... I study programming.
If you are trying to do something a little more specific you can always get rid of the window skin.(easiest way is to replace the original with a blank dummy) then create a custom img and use it as a bg image for your menu. There are also scripts that allow you to change the cursor i believe.
thought about it, but it wouldn't do, as it would require large pictures and I'm trying to optimize it as much as possible.
one of the first things I replaced from the original code was the draw_gauge() method, where instead of pulling a pixel from the window skin, it would pull an entire square, so the gauge would appear *graded*, and from there (having control over the target square and the actual picture), appear as *whatever I say it should look like*
what I'm doing now is taking that, to the entire window skin.
I know how to break down the problem, I've already done that.... the problem now is taking care of the last stage of the solving, which is taking those broken-down elements and putting them back together so they would work as the original Window works, which I don't know because it's not explained anywhere.
I'm on the process of converting the MV code now.... I'll post when I have a result. -
first build after dealing with the code errors.
menu scene
it works.
kinda.
I can use the windows, they respond to triggers and they trigger functions as expected, but they're all messed up.
the title command window doesn't show up at all, but it responds to actions, it looks like it's either invisible, or off the screen.
the HP/MP bars in there, are from the edited window skin, and they draw just fine through the original Window_Base functions inherited from the edited Window object, so the window skin property is being passed correctly, because those Rects are directly grabbed from the top-most parent.
and the face images, and all the details are also made with the Window_Base functions, and since they look fine, I can be sure that *they* accept their parent functions from Window, which is messed up internally, but still gives out what it should give out, as expected.
so,....... yeah. -
update on this.
I managed to un-scramble the mess, and now the new Window object is in place, mostly working.
this is the windowskin I'm currently using.

and this is the menu window, with the parts scrambled on purpose.
the background is now the health bars skin Rect[88,96,8,24], the cursor pointer is the original gradient background Rect[0,0,64,64], and the window frame is the original cursor frame Rect[64,64,32,32], but it's so thin it doesn't show up.

I've found that MV uses Window.setCursorRect() instead of self.cursor_rect.set() from Window_Base, which is a Rect instruction, and MV now handles it from Window, so there were a few issues there with the cursor not updating.
also, since MV uses PIXI to group the entire thing, I had to untie that and group everything under a wrapper which is proving hard to align.
left to do, solve the viewport issues, some relative measurements and drawing order problems, which are causing windows to draw on top of one another, or invisible.
..........it's getting there. -
uhmmmm......
*scratches head*


window.contents.z = 200
window.background.z = 0
background draws on top.
o_O -
little update on this.
solved the draw order issue, apparently specifying a viewport for the internal sprites caused the Z to mess up.
which brings me to this new question, and to why this looks like this (I stripped everything down for clarity, added some coloring, and printed the name and Z value)

the white rectangle is the cursor.
it should be on top of "retrieve", which is the case normally, but for a split second it snaps out and back into place..... I have no idea why.
the scene is a redress of Scene_Shop, and I'm using the same methods (same everything!) for building it.


on Scene_Warehouse:command_buy, it should snap directly to Scene_Shop:command_buy (which is the case) and then hold for user input (which is how I took the picture).
there is no scene update in between (I actually added a Graphics.update in "hold" to get the latest picture) and I added a print of the cursor rectangle, which is in place at 0,0 relative to window_wrhcommand as shown in the console.
but the square is not where it's supposed to be, even after 3 internal updates by the window, as shown in the console. (and nothing is sending it to [9,74]!)
there's a cursor refresh happening somewhere, but I can't find it.
does the program have the custom of making a general refresh of everything in between frames? -
*bump*
-solved the cursor issue (bad call to .activate and refreshcursor)
-solved the draw order issue (bad linking to viewports)
-solved most of the broken-ness, and the final build is getting ready.
I figured I should post
THIS NEAT LITTLE TOOLCode:class Window < Object alias originit initialize def initialize(*args) list |= [] list |= [:dispose,:disposed?,:update,:move,:open?,:close?,:open] list |= [:windowskin,:contents,:move?,:margin] list |= [:cursor_rect,:viewport,:active,:visible] list |= [:arrows_visible,:pause,:x,:y,:width,:height,:z,:ox,:oy,:opacity] list |= [:padding,:padding_bottom,:back_opacity,:contents_opacity,:openness,:tone] list |= [:update_cursor,:cursor_rect,:viewport,:update_tone,:set_tone] originit(*args) #comment out the 'return' below if you want to find whether or not #a window responds to a specific method, listed above return list.each{|method| ismethod = self.respond_to?(method.to_s, true) isaccessor = self.respond_to?(method.to_s+"=",true) isprivate = !self.respond_to?(method.to_s) && self.respond_to?(method.to_s, true) p sprintf("%s, %s, %s", method.to_s, ismethod, isprivate ? "private" : (isaccessor ? "accessor" : "")) p sprintf("%s = %s", method.to_s, self.send(method)) if ismethod && isaccessor } end def printself p self.inspect #add here the properties you want dumped to the console, as symbols list = [:opacity,:back_opacity] #contents rectangle and cursor rectangle, for quick reference to chech #whether a window is loaded and running correctly p "cont #{Rect.new(self.x, self.y, self.width, self.height)}" p "crs #{self.cursor_rect}" list.each{|m| p "#{m}, #{self.send(m)}"} end end module Input def self.hold loop do Graphics.update update break if trigger?(:F8) end end end
which helped me along the way.
usage:
- add "printself" at any given point on any given window to dump the object to the console.
- you can customize the data being dumped by modifying the "list" array, with the corresponding symbol
- add "Input.hold" anywhere in the program to pause the execution. Resume with F8.
EDIT:
here's my last update for thenightmonth, before I burn out completely.
random skin I threw together

how it looks.
not what I'd call artistically pleasing, but you get the idea
nothing is where it's supposed to be, but everything renders where it should.

still to do: redirect draw_gauge() and text_color() to use the new system. -
This thread is being closed, due to being solved. If for some reason you would like this thread re-opened, please report this post and leave a message why. Thank you.
-
[mod]Re-opened at the request of the OP.[/mod]
-
Window Replacement is out.
https://forums.rpgmakerweb.com/index.php?threads/window-object-replacement.99447/

for people who want to design more intricate window skins, and were originally limited by texture size.