Ren'Py Gripes

[Jake]

I'm not sure whether this really qualifies as a gripe or a bug report; it's not stopping me doing anything, but it's something that's not working quite right which is a little annoying (and I'm probably close to having lost a whole man-hour of work on it by now! ;-). I think I brought up on IRC once, but then forgot about it: in OSX, if you bring up Exposé and click on the Ren'Py window, it doesn't bring the Ren'Py window to the front. If you bring up Exposé a second time and click on the Ren'Py window a second time, it brings it to the front as expected.

In 6.10 or earlier, then the Launcher behaved as expected - it would be brought to the front the first time that you clicked on it in Exposé; in 6.11, the Launcher exhibits the same incorrect behaviour that the main Ren'Py window does.

[PyTom]

Jake >>> I honestly have no idea where to even begin debugging this.

[Jake]

Jake >>> I honestly have no idea where to even begin debugging this.

Well, it's hardly the most important thing in the world, obviously - I just mentioned it in case there's some obvious thing that could be changed easily. I've more or less got used to just clicking on the dock icon by now, so it doesn't even bother me as much as it did when I first started developing Ren'Py stuff on the Mac.

Since the Launcher behaved properly in 6.10 and doesn't in 6.11, I wondered if there was some difference in the way the window was being created or consuming OS events or something that might be responsible, or something like that.

[PyTom]

I don't think anything like that changed between 6.10 and 6.11.

[pkt]

Eh, you're probably right about that one. Renpy does pretty well at what it does.

[shahab96]

I have a problem.
My windows version of renpy plays my game well when i launch it from the renpy launcher. But the linux version says that the main menu background is not accesible. I don't have the exaact error report right now because I'm installing maverick, but I'll post it if the problem still occurs. Anyway, I went and checked and the image was there in the specified path with the exact same filename. Oh and if it helps i was using ubuntu lucid 10.04

[Incendium]

Are you sure it is the exact same file name? Linux paths are case sensitive.

[shahab96]

yes, because i made them case sensitive in windows anyway.

[Jake]

yes, because i made them case sensitive in windows anyway.

Along similar lines, have you made sure that any slashes in paths - if you have files in sub-directories of your game directory - are forward slashes ('/') and not backslashes ('\')?

In Windows, you can use either forward- or backslashes in paths equally well, so "gfx\explosion.png" and "gfx/explosion.png" are the same. In Linux, backslashes are generally used for escape codes and aren't valid path separators, so "gfx/explosion.png" is fine but "gfx\explosion.png" will look for a file called "gfx\explosion.png" in your game directory, not a file called "explosion.png" in the 'gfx' directory underneath your game directory.

[shahab96]

yes i made sure of that too. the weirdest thing is that this problem only comes on my main menu. And only with the main menu background whose path i specified in screen language. Also it turns out that the main menu is the only one that uses screen language at this time. And the problem is only in that.

[Formedras]

I have one gripe, that should (but might not actually be) easily fixed or worked around.

I have a character that can choose between two different outfits. (Currently it's the player's character, but I may have another character that would be able to do the same thing.) I'd like to be able to change the definition of the character's image variables dynamically so that one show command works with both outfits.

I attempted this in my personal "basic tests" project using backgrounds; I tried to redefine "bg restest" from being "restest.png" to "restest2.png" and I got nothing, even after giving the "scene bg restest" command. I also tried again, changing scenes to something else first, just in case that was the problem, but it's not.

Am I doing it wrong (i.e. it can't be done with bg series images or something else), or is this currently a limitation of Ren'Py that can or cannot be dealt with?

[PyTom]

Formedras>>> You can use ConditionSwitch or ShowingSwitch to decide which image to use.

[Formedras]

Ok. That may not have been the method I was thinking of, but the result'll be the same. Thanks.

Plus, I just realized, that the way I'm doing scripting my VN, it may be better this way than the method I was describing.

[kuroi]

I have a gripe! Renpy is just too damn awesome. It makes my life too much easier. Not having to code a game engine from scratch just saves me more time than I know what to do with.

[Ren]

Hi, there's one thing I really dislike, but I realise I may be the only one disliking it (and it's not just Ren'Py doing it... ): I remembered it today while I was playing something, and when I put the game in full screen I could see the rough edges of the characters wings and all that.
I essentially always play games in windowed mode, because I hate to see them not in their native resolution as I hate to see the pixels in the art's line-art, for example - but I end up finding the stuff in my desktop such as icons and whatnot... distracting. Seeing them doesn't totally let me dive into the story, but seeing the art blown to a higher size than it should be distracts me just as much.

Long story short: would you perhaps consider adding a third way to see visual novels which lets you see the game at its native size, but with a black background?

Thanks in advance for any input on this!