Ren'Py Gripes
- PyTom
- Ren'Py Creator
- Posts: 16088
- Joined: Mon Feb 02, 2004 10:58 am
- Completed: Moonlight Walks
- Projects: Ren'Py
- IRC Nick: renpytom
- Github: renpytom
- itch: renpytom
- Location: Kings Park, NY
- Contact:
Re: Ren'Py Gripes
Ren>>> Can you think of a good name for this mode?
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom(When was the last time you backed up your game?)
Software > Drama • https://www.patreon.com/renpytom
Re: Ren'Py Gripes
I think I can: Jack mode, after You Don't Know Jack, which does this exact thing. (Except that they first make it a white background during the pre-game, then when the game starts, it turns black.)PyTom wrote:Ren>>> Can you think of a good name for this mode?
Of course, suggesting this name could just be idiocy, even if the reason for it is sound. (And it is.)
Re: Ren'Py Gripes
Perhaps something like "Framed" or "Picture frame", since the game is somehow framed in the black background?
Or maybe "Full-screen alternative"? "Awesome mode"? "Cinema mode"? "I can't come up with decent names for beans mode"?
Or maybe "Full-screen alternative"? "Awesome mode"? "Cinema mode"? "I can't come up with decent names for beans mode"?
-
- Eileen-Class Veteran
- Posts: 1406
- Joined: Fri Feb 17, 2006 12:47 pm
- Completed: http://rd2k2-games.blogspot.com
Re: Ren'Py Gripes
Suggestions
-Correct Full Screen Ratio Mode
-Bordered Full Screen Mode
-Correct Full Screen Ratio Mode
-Bordered Full Screen Mode
How do you make your games? I see. Thank you for the prompt replies, but it is my considered opinion that you're doing it wrong inefficiently because I am a perfushenal professional. Do it my way this way and we can all ascend VN Nirvana together while allowing me to stroke my ego you will improve much faster. Also, please don't forget to thank me for this constructive critique or I will cry and bore you to death respond appropriately with a tl;dr rant discourse of epic adequately lengthy proportions. - Sarcasm Veiled in Euphemism: Secrets of Forum Civility by lordcloudx (Coming soon to an online ebook near you.)
- PyTom
- Ren'Py Creator
- Posts: 16088
- Joined: Mon Feb 02, 2004 10:58 am
- Completed: Moonlight Walks
- Projects: Ren'Py
- IRC Nick: renpytom
- Github: renpytom
- itch: renpytom
- Location: Kings Park, NY
- Contact:
Re: Ren'Py Gripes
I'll note that this would be going in the Display preferences section, so it has to be relatively short - probably a single word, and one that has to be relatively self-explanatory. "Framed" seems like a reasonable choice for this.
The basic feature request seems reasonable - and so I'll add it. I'm not sure when, as it won't be until the next time I touch that code.
The basic feature request seems reasonable - and so I'll add it. I'm not sure when, as it won't be until the next time I touch that code.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom(When was the last time you backed up your game?)
Software > Drama • https://www.patreon.com/renpytom
Re: Ren'Py Gripes
6.11.1
Wish: reuse existing JEditor window for RenPy generated files.
Explanation: I hit project edit button, Renpy opens JEditor in a new window with tabs (buffers) for each game (.rpy) file. I edit, save, and run. There is an error and RenPy creates traceback.txt and opens it and everything else in a *NEW* JEditor window. Now I have to close the previous window, lest things get out of sync from editing the same file from two different windows. I would prefer that it add the file to the existing window if at all possible. My memory is that it did this with the previous editor, though that could be a false memory.
Wish: reuse existing JEditor window for RenPy generated files.
Explanation: I hit project edit button, Renpy opens JEditor in a new window with tabs (buffers) for each game (.rpy) file. I edit, save, and run. There is an error and RenPy creates traceback.txt and opens it and everything else in a *NEW* JEditor window. Now I have to close the previous window, lest things get out of sync from editing the same file from two different windows. I would prefer that it add the file to the existing window if at all possible. My memory is that it did this with the previous editor, though that could be a false memory.
Re: Ren'Py Gripes
Seconded. I seem to recall being able to make it do this on Windows, editing one of the various config files, but I haven't got anywhere on Mac. :/tjreedy wrote: Wish: reuse existing JEditor window for RenPy generated files.
(At least the newer version of JEdit included in more-recent builds of Ren'Py has stopped crashing with out-of-memory exceptions after the tenth or so extra load!)
I seem to recall PyTom saying he was looking around at other editors, but it was low priority, though - so I wouldn't be surprised if this never gets fixed specifically with JEdit...
Server error: user 'Jake' not found
-
- Newbie
- Posts: 11
- Joined: Sun May 24, 2009 12:15 am
- Contact:
Re: Ren'Py Gripes
I dunno, I think that's more an issue with jEdit than Ren'Py. I use Geany and this isn't a problem; it opens new tabs just fine.
-
- Regular
- Posts: 100
- Joined: Fri Oct 02, 2009 2:32 pm
- Projects: American Jurassic
- Organization: Pier 7 Media
- Location: Arizona
- Contact:
Re: Ren'Py Gripes
The most prominent reason for this happening is that the routine that launches error.txt passes an argument which forces transient mode.tjreedy wrote:Explanation: I hit project edit button, Renpy opens JEditor in a new window with tabs (buffers) for each game (.rpy) file. I edit, save, and run. There is an error and RenPy creates traceback.txt and opens it and everything else in a *NEW* JEditor window. Now I have to close the previous window, lest things get out of sync from editing the same file from two different windows. I would prefer that it add the file to the existing window if at all possible. My memory is that it did this with the previous editor, though that could be a false memory.
Open renpy/parser.py and scroll all the way down to the bottom:
Code: Select all
try:
if renpy.config.editor:
renpy.exports.launch_editor([ 'errors.txt' ], 1, transient=1)
else:
os.startfile('errors.txt') # E1101
except:
pass
return True
Code: Select all
if sys.platform == 'win32':
config.editor = 'javaw.exe -jar "' + editor + '" -reuseview -background "%(filename)s" +line:%(line)d "%(otherfiles)s"'
config.editor_transient = 'javaw.exe -jar "' + editor + '" -newplainview "%(filename)s" +line:%(line)d "%(otherfiles)s"'
else:
config.editor = 'java -jar "' + editor + '" -reuseview -background "%(filename)s" +line:%(line)d "%(otherfiles)s"'
config.editor_transient = 'java -jar "' + editor + '" -newplainview "%(filename)s" +line:%(line)d "%(otherfiles)s"'
According to jEdit's docs, jEdit is supposed to require "-background" as an argument in order to be able to listen for "-reuseview" (otherwise the command line generates separate instances). In practice this seems to be more of an issue for Windows users.
Tom, I'd rather see a preference pane in Options with "new window|same window" checkboxes for each of the logs than manually hunt down and edit separate function calls.
For those who don't want to wait for this to be fixed, the equivalent function call for traceback.txt is in renpy/bootstrap.py.
- Aleema
- Lemma-Class Veteran
- Posts: 2677
- Joined: Fri May 23, 2008 2:11 pm
- Organization: happyB
- Tumblr: happybackwards
- Contact:
Re: Ren'Py Gripes
Ren'Py gripes. I has them.
I just spent the most excruciating, frustrating day working on Ren'Py today. I updated my project to 11.2 to make use of the features, but this broke several screens. By "broke", I mean they didn't look right. The UI widgets are still very much supported, but the way some of them behave has changed. I kept a journal of my experiences learning the screen language to rebuild this broken screens in SL. Warning! It is not pretty, may just be the side effect of being alienated from a language I was very comfortable with, and just may be general bitchiness in general:
- imagebutton ... I name my hover/idle images 1 and 2 (back1.png, back2.png), which is way easier to type than 4-5 letter words. My punishment is having to type them anyway, apparently. So now I have the option to rename all my files (hahaha, no), or practice better naming conventions for future files. So I can either: name them idle/hover straight out of photoshop for the 6 characters "auto %s" take (15 keystrokes total), or continue naming them 1, 2 but have to now type idle/hover in their code (11 chars). The fact I had to just weigh the options doesn't really make either more convienient to me anymore. Maybe this is just me, but I like saving keystrokes ... and the old ui.imagebutton widget only needs a comma to tell which was which.
- ui.image was completely removed but I spent ten minutes looking for the equivilant. Had no idea to just use "add" instead, but I figured it out, so *shrugs* Doesn't seem intuitive since "image" or "show" isn't in the name, and I rarely/never used ui.add, so it didn't translate well for me.
- battled an "unsupported operand type(s) for -: 'float' and 'str'" error for twenty minutes. I've finally figured out because it was I transfered over "center" instead of 0.5 in many of my widgets.
- I had a "spacing=5" in my old ui.side that I couldn't find a place for in the new language. Putting it with the "side:" line and after it both resulted in errors, but it's shown in actual other examples like the window one, but it says it's not recognized as a "side" child.
- had to change dyanmic file calls that had variables in them like, "root/"+string+".png" or "root/%s.png"%string, because these BROKE the script. Looking back over documentation, looks like we had to do some roundabout reassigning so that we made a variable dynamic and then called that variable. In this aspect, SL is making life more complicated, not simpler. I would love to be wrong about this, so correct me if I am. But since that's just downright BS, I opted to use the original ui widgets I had those dynamic calls in ...
- but it doesn't matter what I do because the SL still cropped the images! This is what I was fixing by rebuilding the screens in the first place, so I'm rethinking trying to learn SL in the first place if the old system and the new system behave in the same annoying way. SL cuts off the images for (then) unknown reasons, perhaps some arbitraty xminimum or something had to be set but I couldn't find out why. This was never the case before, and it's really pissing me off.
- I tried to fix the cropping images issue I said above, but putting "xminimum" under hbox/vbox isn't recognized!? Y U HATE ME SL? Looking further at documentation, I guess we're supposed to use "Area" for things ...? W ... why? I have to use it or my images will be cut off? I did figure out my images were cutting themselves off because I either set them to + or - positions, out of whatever the engine thought the area was without defining it. I really don't like how each area has a limited view port and if you don't draw inside of it, it doesn't exist. Because I do NOT know how big each vbox or hbox needs to be beforehand, I just know I need stuff to stack on top of or next to each other, and forcing me to calculate every time is way more trouble than whatever the Area() function was made to make convienient.
- Not making the python language intrisincally supported in the SL as forced me to put those silly dollar signs in front of EVERYTHING. Not to mention the python-only things like "when" (but the SL can't be supported IN python!!) even though I have screens that use it. >_< Again, keystrokes you have not saved me. You'll remove commas and equal signs (SGIJDfg;iusdfhoiud;fhg), but everything else must be done in an overly elaborate fashion? MAYBE if it even still works!?
Had to rant this. 6+ hours making a screen I've already made with several intervals where I wanted to smash my keyboard and throw my mouse (I RARELY get that angry with this stuff), I feel I can at least let the creator know what someone who was already comfortable with the GUI system thought while learning the new one. I already know what a frame, hbox, and thumb are ... Now imagine this with someone who knows jack about it. =P I'd rather continue using the UI functions, not because I know it better, but because even though they have the same downfalls now, SL has less flexibility and requires me to "trick" it into doing what I want it to.
To counteract this post, here are things I like about SL:
- I love that ui.close() is gone. Obliterated. Sayonara, no one misses you. Using blocks for widgets with children is AWESOME. It's so much easier to follow the flow of things, because I usually have layers upon layers of things that needed ui.closes. This is my favorite feature.
- We now have much more control over game screens, and basically all features! Recreating the save/load screen was something I couldn't even begin to do. We can do things with them that were just dreams a while ago, and I appreciate this a lot.
- the "auto" feature for selecting files is awesome, but it's currently be implemented for words I've never used to represent alterations outside of the 5-piece menu imagemaps. Little casual 2-state buttons I make aren't worth the time it takes to type out "_hover/idle" after each of them. But I do like the idea of just defining one image location and having the engine find both alterations on its own. I'm not going to be using it though, for reasons already described.
- Area() has the potential to be awesome, but I've yet to use that potential, and it's just f*ing everything up at the moment.
- That ui.bar and other things that didn't originally show up outside of the viewport are now showing up!! I don't have to do roundabout image checks and can just use a bar like intended.
- Just the general recognition that a screen isn't the regular VN character-background-text situation so it reacts appropriately.
I apologize. >_< It doesn't help I was trying to recreate one of the more complicated screens in my game.
I just spent the most excruciating, frustrating day working on Ren'Py today. I updated my project to 11.2 to make use of the features, but this broke several screens. By "broke", I mean they didn't look right. The UI widgets are still very much supported, but the way some of them behave has changed. I kept a journal of my experiences learning the screen language to rebuild this broken screens in SL. Warning! It is not pretty, may just be the side effect of being alienated from a language I was very comfortable with, and just may be general bitchiness in general:
- imagebutton ... I name my hover/idle images 1 and 2 (back1.png, back2.png), which is way easier to type than 4-5 letter words. My punishment is having to type them anyway, apparently. So now I have the option to rename all my files (hahaha, no), or practice better naming conventions for future files. So I can either: name them idle/hover straight out of photoshop for the 6 characters "auto %s" take (15 keystrokes total), or continue naming them 1, 2 but have to now type idle/hover in their code (11 chars). The fact I had to just weigh the options doesn't really make either more convienient to me anymore. Maybe this is just me, but I like saving keystrokes ... and the old ui.imagebutton widget only needs a comma to tell which was which.
- ui.image was completely removed but I spent ten minutes looking for the equivilant. Had no idea to just use "add" instead, but I figured it out, so *shrugs* Doesn't seem intuitive since "image" or "show" isn't in the name, and I rarely/never used ui.add, so it didn't translate well for me.
- battled an "unsupported operand type(s) for -: 'float' and 'str'" error for twenty minutes. I've finally figured out because it was I transfered over "center" instead of 0.5 in many of my widgets.
- I had a "spacing=5" in my old ui.side that I couldn't find a place for in the new language. Putting it with the "side:" line and after it both resulted in errors, but it's shown in actual other examples like the window one, but it says it's not recognized as a "side" child.
- had to change dyanmic file calls that had variables in them like, "root/"+string+".png" or "root/%s.png"%string, because these BROKE the script. Looking back over documentation, looks like we had to do some roundabout reassigning so that we made a variable dynamic and then called that variable. In this aspect, SL is making life more complicated, not simpler. I would love to be wrong about this, so correct me if I am. But since that's just downright BS, I opted to use the original ui widgets I had those dynamic calls in ...
- but it doesn't matter what I do because the SL still cropped the images! This is what I was fixing by rebuilding the screens in the first place, so I'm rethinking trying to learn SL in the first place if the old system and the new system behave in the same annoying way. SL cuts off the images for (then) unknown reasons, perhaps some arbitraty xminimum or something had to be set but I couldn't find out why. This was never the case before, and it's really pissing me off.
- I tried to fix the cropping images issue I said above, but putting "xminimum" under hbox/vbox isn't recognized!? Y U HATE ME SL? Looking further at documentation, I guess we're supposed to use "Area" for things ...? W ... why? I have to use it or my images will be cut off? I did figure out my images were cutting themselves off because I either set them to + or - positions, out of whatever the engine thought the area was without defining it. I really don't like how each area has a limited view port and if you don't draw inside of it, it doesn't exist. Because I do NOT know how big each vbox or hbox needs to be beforehand, I just know I need stuff to stack on top of or next to each other, and forcing me to calculate every time is way more trouble than whatever the Area() function was made to make convienient.
- Not making the python language intrisincally supported in the SL as forced me to put those silly dollar signs in front of EVERYTHING. Not to mention the python-only things like "when" (but the SL can't be supported IN python!!) even though I have screens that use it. >_< Again, keystrokes you have not saved me. You'll remove commas and equal signs (SGIJDfg;iusdfhoiud;fhg), but everything else must be done in an overly elaborate fashion? MAYBE if it even still works!?
Had to rant this. 6+ hours making a screen I've already made with several intervals where I wanted to smash my keyboard and throw my mouse (I RARELY get that angry with this stuff), I feel I can at least let the creator know what someone who was already comfortable with the GUI system thought while learning the new one. I already know what a frame, hbox, and thumb are ... Now imagine this with someone who knows jack about it. =P I'd rather continue using the UI functions, not because I know it better, but because even though they have the same downfalls now, SL has less flexibility and requires me to "trick" it into doing what I want it to.
To counteract this post, here are things I like about SL:
- I love that ui.close() is gone. Obliterated. Sayonara, no one misses you. Using blocks for widgets with children is AWESOME. It's so much easier to follow the flow of things, because I usually have layers upon layers of things that needed ui.closes. This is my favorite feature.
- We now have much more control over game screens, and basically all features! Recreating the save/load screen was something I couldn't even begin to do. We can do things with them that were just dreams a while ago, and I appreciate this a lot.
- the "auto" feature for selecting files is awesome, but it's currently be implemented for words I've never used to represent alterations outside of the 5-piece menu imagemaps. Little casual 2-state buttons I make aren't worth the time it takes to type out "_hover/idle" after each of them. But I do like the idea of just defining one image location and having the engine find both alterations on its own. I'm not going to be using it though, for reasons already described.
- Area() has the potential to be awesome, but I've yet to use that potential, and it's just f*ing everything up at the moment.
- That ui.bar and other things that didn't originally show up outside of the viewport are now showing up!! I don't have to do roundabout image checks and can just use a bar like intended.
- Just the general recognition that a screen isn't the regular VN character-background-text situation so it reacts appropriately.
I apologize. >_< It doesn't help I was trying to recreate one of the more complicated screens in my game.
- PyTom
- Ren'Py Creator
- Posts: 16088
- Joined: Mon Feb 02, 2004 10:58 am
- Completed: Moonlight Walks
- Projects: Ren'Py
- IRC Nick: renpytom
- Github: renpytom
- itch: renpytom
- Location: Kings Park, NY
- Contact:
Re: Ren'Py Gripes
This was an oversight. It will be coming back.Aleema wrote: - ui.image was completely removed but I spent ten minutes looking for the equivilant. Had no idea to just use "add" instead, but I figured it out, so *shrugs* Doesn't seem intuitive since "image" or "show" isn't in the name, and I rarely/never used ui.add, so it didn't translate well for me.
This should work, though - the styles module should translate it. Do you remember the code that was causing the problem?- battled an "unsupported operand type(s) for -: 'float' and 'str'" error for twenty minutes. I've finally figured out because it was I transfered over "center" instead of 0.5 in many of my widgets.
Another oversight, that will be fixed shortly.- I had a "spacing=5" in my old ui.side that I couldn't find a place for in the new language. Putting it with the "side:" line and after it both resulted in errors, but it's shown in actual other examples like the window one, but it says it's not recognized as a "side" child.
These you need to put in parentheses. So ("root/"+string+".png") should work.- had to change dyanmic file calls that had variables in them like, "root/"+string+".png" or "root/%s.png"%string, because these BROKE the script. Looking back over documentation, looks like we had to do some roundabout reassigning so that we made a variable dynamic and then called that variable. In this aspect, SL is making life more complicated, not simpler. I would love to be wrong about this, so correct me if I am. But since that's just downright BS, I opted to use the original ui widgets I had those dynamic calls in ...
Do you have an example of where SL is cropping images? It's possible that the GL support is doing this, but unless clipping is enabled, it never should. I'd reallly like to see an example of this, and how it differs between 6.10 and 6.11.- but it doesn't matter what I do because the SL still cropped the images! This is what I was fixing by rebuilding the screens in the first place, so I'm rethinking trying to learn SL in the first place if the old system and the new system behave in the same annoying way. SL cuts off the images for (then) unknown reasons, perhaps some arbitraty xminimum or something had to be set but I couldn't find out why. This was never the case before, and it's really pissing me off.
The behavior of xminimum with respect to vbox and hbox is very weird, and very different to what happens with buttons and windows. For vbox and hbox, the only affect of xminimum is to set the minimum maximum size of the horizontal area. That's a weird thing to do, so it's gone.- I tried to fix the cropping images issue I said above, but putting "xminimum" under hbox/vbox isn't recognized!? Y U HATE ME SL? Looking further at documentation, I guess we're supposed to use "Area" for things ...? W ... why? I have to use it or my images will be cut off? I did figure out my images were cutting themselves off because I either set them to + or - positions, out of whatever the engine thought the area was without defining it. I really don't like how each area has a limited view port and if you don't draw inside of it, it doesn't exist. Because I do NOT know how big each vbox or hbox needs to be beforehand, I just know I need stuff to stack on top of or next to each other, and forcing me to calculate every time is way more trouble than whatever the Area() function was made to make convienient
How were you using xminimum with hbox and vbox? Were there other properties involved?
Area is just one option, used for buttons and things that have to be a fixed size. For variable size things, you can still use xpos/ypos, or the new pos property, and it works. (Does the clipping of images have something to do with area?)
The goal of the screen language was to make user interface design reasonably similar to the rest of Ren'Py, linguistically. Ren'Py statements tend to match:
<keyword> <required arguments> ( <property-name> <property-value> )*
Where * means 0-or-more. Screen language tends to match this design philosophy.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom(When was the last time you backed up your game?)
Software > Drama • https://www.patreon.com/renpytom
Re: Ren'Py Gripes
Not sure if this has been posted already, but it's a bit of a problem when copying and pasting something into Ren'Py. I've been writing my story in Word and when I copied and pasted it in, it crashed. I had to manually retype every single "" on every single line to get it working. Maybe I just messed up somehow, but that's about it.
-
- Regular
- Posts: 195
- Joined: Tue Dec 15, 2009 4:20 am
- Projects: The Duke's Daughter
- Location: Cape Town
- Contact:
Re: Ren'Py Gripes
This is because you've got smart quotes on in word, which replaces regular quotation marks with left and right quotation marks. Renpy only recognizes the plain quotation marks, which is why the game didn't work.
ways to get around this are to turn of smart quotes in word or do a search and replace once you've pasted it into renpy for left quote and right quote and replace with the regular quote (use the actual quote symbols in the search boxes).
ways to get around this are to turn of smart quotes in word or do a search and replace once you've pasted it into renpy for left quote and right quote and replace with the regular quote (use the actual quote symbols in the search boxes).
Mental weather report: Cloudy with a possibility of brain storms.
- jack_norton
- Lemma-Class Veteran
- Posts: 4084
- Joined: Mon Jul 21, 2008 5:41 pm
- Completed: Too many! See my homepage
- Projects: A lot! See www.winterwolves.com
- Tumblr: winterwolvesgames
- Contact:
Re: Ren'Py Gripes
A suggestion/complaint I had from a player, but to be honest he's right since it's how in most other games works:
It can be very useful in certain situations... like when playing at work!!
so if pytom wants to kindly put this into the TODO list...On Windows (XP) box hitting the Windows Key (which minimizes the game), the music continues to play. This also occurs when in the game is running in windowed mode and you click the minimize button. Since this is something a user does when they need to do something non-game related, the music should really stop.
It can be very useful in certain situations... like when playing at work!!
Who is online
Users browsing this forum: No registered users