Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

The selected displayable stack includes background?

A topic by Konayachi created 43 days ago Views: 88 Replies: 12
Viewing posts 1 to 9

Hi! I've been playing with guiManipulate for a while now and it has been very helpful to position things around. Thank you! ^^

There is this behavior that I don't really understand:

Whenever I select any button, the stack this tool accesses seems to include the background.

This GIF may explain it better:


After "ImageButton", there is "Image  screens.rpy:568", "ImageReference", and "Transform".
The first "Image" at screen.rpy:568 is actually the background image. In my file, it is:

add gui.main_menu_background

Why is the background part of the stack even when I only select the button?
Also, I find it kind of weird that the stack it displays in the displayable goes from bottom (Image) to top (Transform), while in the GUI itself it's actually the opposite: from top to bottom.
Does that make sense...?

It doesn't bother me much, but most of the time I only need the tool to select up to the "ImageButton" and nothing more than that.
When I want to go back and forth between "Image" and "ImageButton", I have to go through all the way to "Transform" each time. So, it's a little bit frustrating...
But, I managed it okay so far. The tool helps me getting the rough pos each time so after getting the numbers the first time, I only need a few modifications to get to the exact position that I want.

I'm very new in GUI coding, so any pointers are very appreciated.

Thank you in advance!

(+1)

Sorry about the delay. itch.io was down.

Ok. I see that some of my design decisions are leading you to these questions. I'll address them one-by-one

The stack when selecting

When you start selecting something, the tool gets everything that is in the 2D plane of the mouse. In other words, regardless of what is on top of it, it gets everything that is part of that position on screen. That is done by Ren'Py's internal undocumented API.

Think like you have an A2 size table with lots of A4 sheets of paper. Then you get a knife and pierce through all sheets anywhere on the table. The ones the knife pierces through are the ones part of the stack obtained. That's basically what this does.

The background image (more exactly, Displayable) is just an image like any other, for Ren'Py. There's no way to distinguish. Also, if it's always covered, it would be impossible to select it without hacks or annoying processes. So I ended up going with this process.

It is both not trivial to know when the thing you selected ended and when the next thing starts. It is possible to have some tricks that usually work but not in the rare times which is usually when it's most frustrating.

Sorting of the stack

The way the stack is sorted is just a UX decision I did. It had to be sorted in some shape or form. I decided to go from bottom to top due to how the levels look like and are build, so it's increasingly "upwards" when looked at in the UI but also, first select the "closest" to the mouse. If you have a better idea, I can take it into account.

Going all the way when trying to select in the opposite way

When I need that, I usually just press Esc and then m again. However, rule of thumb with this tool is to edit 1 or 2 things at a time and then edit in the source code which makes it reload. However, in this case, it seems like what you want is to move the button and then the text, for example.
One thing I can consider is that if you move more than some small amount or some time passed, the next to be selected resets to the first one when you press, in this case, m again. Would that help? Or would having a button to go the opposite way help more? Using n while in move mode, perhaps?

Rough pos each time

You mention:

The tool helps me getting the rough pos each time

The tool is designed to get the exact position you want much more fast than with editing in your editor and reloading. Is it failing to do that for you?


Offtopic:
I read the Ice cream culprit. It was really good and funny! Keep up the work! I'm a fan now.

No problem at all!

1. The stack when selecting: I see. It sounds quite complicated for me haha, but I think I get the idea. Many times I think Ren'Py works just like CSS/HTML, like how the background(-image) and the image(img) are different.

2. Sorting the stack: I can't think of any new ideas for now, but I think making it as close as how it visually looks like would be more UX friendly. In this case, the buttons which are in front of the background is stacked first, and the background is stacked later. Depending on whether I understand how this tool works, this suggestion may or may not work.

This reminds me of how Ren'Py's native inspector tool (Shift+I) is displaying information.

3. Going all the way when trying to select in the opposite way: I think this is related to the first two topics. 'n' and 'm' to move back and forth sounds interesting, I wonder how hard it is to implement it. Probably not hard? XD

4. Rough pos: aah sometimes when I just want to move a few pixels, I just change the number manually myself. I know I could have used the tool to shorten this process. Like, looking back, isn't this tool meant to speed up that process? Integrating this tool to my Ren'Py coding is very new so I have to adjust that workflow... I guess it's time to familiarize myself with it. So, nevermind haha. >.<

And thank you for playing Ice Cream Culprit!! I hope you get a nice ice cream (or any sweets) of your liking as well haha.

(sorry. I answered outside the thread)

  1. Yeah. I'd say there's some inspiration from HTML+CSS when Tom did Ren'Py's code architecture for the UI. However, there's clear simplifications all around whenever it was feasible. This is one of them.
  2. I'm not sure what do you mean... Do you mean to have the reverse order for the list that appears? This is actually the same API that Ren'Py uses for the inspector Tool to work.
  3. Yeah. That's fine to implement at some point. N would only work after pressing M but I think that shouldn't be a problem.
  4. No problem.

No, you're right. I should have replied on the main post! I'll continue there! :D

  1. Yeah. I'd say there's some inspiration from HTML+CSS when Tom did Ren'Py's code architecture for the UI. However, there's clear simplifications all around whenever it was feasible. This is one of them.
  2. I'm not sure what do you mean... Do you mean to have the reverse order for the list that appears?
    This is actually the same API that Ren'Py uses for the inspector Tool to work.
  3. Yeah. That's fine to implement at some point. N would only work after pressing M but I think that shouldn't be a problem.
  4. No problem.

1. I agree!

2. Well let me try to put this visually since I'm not good in explaining in words:


(very bad visual, sorry haha but) do you get what I am trying to explain here?
Basically it's to have the information goes from the top (button) to bottom (background), visually.

Though I know that Ren'Py itself does the same thing from bottom to top...

If by any chance this is because of whatever I fail to understand from your explanation, then let me know please. I'll learn more!
Please be patient with me. ´~` )9;;;

3 and 4. That's really cool!! Nice!!

Ah yes. I think I get the idea. If you rotate that way, more like a piece of paper on the table, that would definitely happen. I checked the code about how would it be to implement that. It's not impossible but that one is a bit harder. The hardest part of that solution is the need to invert the levels. Basically, I'd need to figure out first what's the nth of the thing on top (the button in your example) so I can invert the subtraction.

More like 

maximum_level - level 

instead of just 

level 

. Quite feasible. Just takes some extra work.

(1 edit)

I see. But the default ren'py's Displayable Inspector also lists the displayables from the back to front as well, right?
I think it makes the most sense to do the same as the default Displayable Inspector to not confuse users that way...

One interesting thing: sometimes I use guiManipulate just to get information about where in my file is this button coded XD especially in older projects where I don't remember things. I know it's not designed for such purpose, but I like the way it can tell me, for example, like this certain button is coded in this file, on this line.  A simple 'tell me where is this' which is still on-screen. Well... I know Displayable Inspector does this, but I have a hard time getting used to how it's displayed in a whole new screen and covers everything I'm working on. So, guiManipulate kiiiinds of does what Displayable Inspector does as well nicely haha.

True. I'll keep it as is now then. I will still implement the n when I have time to also test it works.

Let me see if I get it:
You would like to have a "take me to the source code of this" kind of addon for Renpy? You activate it, then click on the thing where you want to go the source code of and you end up there?

Sorry for the late reply!! I was away for a few days >o<

"take me to the source code of this" kind of addon

Do you mean something that connects between the VN window and the code editor window? o.O
That sounds interesting actually. Like, sometimes when I'm working on a function in my VNs, I would think of the pseudo-flowchart kind of how would things be, code it down (someone helped me coded the actual thing tbh), and test it back and forth between the VN and the code editor window. A tool or addon that can speed this up would be quite interesting to have!

That gives me an idea. I know a JAM that will come soon. Maybe I can do that for that JAM. I'll let you know when I have an initial version for you to check if it looks good.

(+1)

:O please keep me updated!! :D Good luck!!