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.