Ren'Py just wanted to ask does this code still works to scale in renpy or am i inputing the code wrong

[DoverUK25]

Hi, guys just doing a test build while following a renpy tutorial on youtube. Is this code right for scaling the pictures in renpy? Keeps giving me errors.

 

[MissFortune]

What error is it throwing, exactly? Seeing one line of code is hardly helpful. Have you tried using the actual image file name with its extension?

image picture_1 = im.Scale("pic_1.png", 1920, 1080)

 

[MidnightArrow]

No, it's

You must be registered to see the links

now apparently. I'd probably just use ATL though, with the "zoom" property.

In case you're confused (because the documentation for FactorScale doesn't explain this), you need to go to

You must be registered to see the links

to learn that images can be used in lieu of image manipulators, so where it takes the "im" argument you can substitute a regular old image in its place. Gee, I fucking love duck typing!

(Edit: Actually it says that at the top of the same page too, which I missed because I immediately went to the function I actually care about, but I just wanted an excuse to rag on Python for being a shit language for not having types.)

Ren'py's current documentation sucks but it's better than relying on old Youtube tutorials that reference outdated (but still sucky) documentation.

And I agree that if you say "it's giving me error messages" you should probably post the error messages. Another problem is you may need to wrap the image name inside renpy.displayable("pic_1") or Image("pic_1") or whichever one of the six different ways to turn a string into a displayable the image manipulator code will accept.

 

[DoverUK25]

I'm sorry, but an uncaught exception occurred.

While running game code:
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "game/script.rpy", line 8, in <module>
image pictuer_1 = im.scale("pic_1", 1920,1080)
AttributeError: 'module' object has no attribute 'scale'

-- Full Traceback ------------------------------------------------------------

Full traceback:
File "renpy/bootstrap.py", line 331, in bootstrap
renpy.main.main()
File "renpy/main.py", line 560, in main
renpy.game.context().run(node)
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "renpy/ast.py", line 1027, in execute
img = renpy.python.py_eval_bytecode(self.code.bytecode)
File "renpy/python.py", line 2269, in py_eval_bytecode
return eval(bytecode, globals, locals)
File "game/script.rpy", line 8, in <module>
image pictuer_1 = im.scale("pic_1", 1920,1080)
AttributeError: 'module' object has no attribute 'scale'

sorry forgot to post this as well

 

[MissFortune]

I'm sorry, but an uncaught exception occurred.

While running game code:
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "game/script.rpy", line 8, in <module>
image pictuer_1 = im.scale("pic_1", 1920,1080)
AttributeError: 'module' object has no attribute 'scale'

-- Full Traceback ------------------------------------------------------------

Full traceback:
File "renpy/bootstrap.py", line 331, in bootstrap
renpy.main.main()
File "renpy/main.py", line 560, in main
renpy.game.context().run(node)
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "renpy/ast.py", line 1027, in execute
img = renpy.python.py_eval_bytecode(self.code.bytecode)
File "renpy/python.py", line 2269, in py_eval_bytecode
return eval(bytecode, globals, locals)
File "game/script.rpy", line 8, in <module>
image pictuer_1 = im.scale("pic_1", 1920,1080)
AttributeError: 'module' object has no attribute 'scale'

sorry forgot to post this as well

Depending on your version of Ren'py, you might want to try capitalizing the S in scale. Instead of "im.scale", try "im.Scale."

 

[DoverUK25]

This is what I'm trying to rescale. I'm using renpy 7.4.11. I tried to use Scale still didn't work.

 

[MissFortune]

I mean, is there a reason you're just not scaling the image itself down to 1080? Seems like a basic scale down in PS/GIMP/etc. would make your life a lot easier.

 

[Count Morado]

I'm sorry, but an uncaught exception occurred.

While running game code:
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "game/script.rpy", line 8, in <module>
image pictuer_1 = im.scale("pic_1", 1920,1080)
AttributeError: 'module' object has no attribute 'scale'

-- Full Traceback ------------------------------------------------------------

Full traceback:
File "renpy/bootstrap.py", line 331, in bootstrap
renpy.main.main()
File "renpy/main.py", line 560, in main
renpy.game.context().run(node)
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "game/script.rpy", line 8, in script
image pictuer_1 = im.scale("pic_1", 1920,1080)
File "renpy/ast.py", line 1027, in execute
img = renpy.python.py_eval_bytecode(self.code.bytecode)
File "renpy/python.py", line 2269, in py_eval_bytecode
return eval(bytecode, globals, locals)
File "game/script.rpy", line 8, in <module>
image pictuer_1 = im.scale("pic_1", 1920,1080)
AttributeError: 'module' object has no attribute 'scale'

sorry forgot to post this as well

Spell check. You have a typo.

 

[MidnightArrow]

im.Scale no longer exists. It's im.FactorScale, like I said earlier. The page I linked to says all the image manipulators are deprecated anyway, so you shouldn't use them anymore because they'll probably get removed like im.Scale was.

image picture_1:
    "pic_1"
    zoom 0.5

That's the best way to do it now, afaik. Can't remember which way zoom goes so you might need to invert it (use 2.0 instead).

 

[crabsinthekitchen]

im.Scale no longer exists

really? I mean, my version is not the same as his but if it was removed I'd expect it to be gone from the latest RenPy too

 

[anne O'nymous]

Spell check. You have a typo.

He have a typo, but not the one you pointed.

He wrote im.scale, while it's im.Scale.

im.Scale no longer exists.

It's depreciated, but not removed.

 

[MidnightArrow]

really? I mean, my version is not the same as his but if it was removed I'd expect it to be gone from the latest RenPy too
View attachment 2227804

I see you're right. I assumed it was removed because it isn't in the list of image manipulators, but I guess it was due to the typo instead.

However it doesn't really matter. If something is deprecated and undocumented, that means it could be removed at any time or has major flaws, and you absolutely should not use it unless you need to maintain legacy code. Even if it technically still works, it's very poor practice. So for all intents and purposes, just imagine it doesn't exist anymore.

 

[MissFortune]

If something is deprecated and undocumented, that means it could be removed at any time or has major flaws, and you absolutely should not use it unless you need to maintain legacy code.

I agree. But by it being removed at any time, I'd think that would demand an update of Ren'py itself, no? Which would essentially mean updating in the middle of a project, which isn't recommended for this reason.

 

[anne O'nymous]

If something is deprecated and undocumented, that means it could be removed at any time or has major flaws, and you absolutely should not use it unless you need to maintain legacy code.

No.

If something is deprecated, it's because it was replaced (like here by im.FactorScale), and only for that reason. As for the flaws, they are fixed, not hidden under the carpet.

As for the risk for it to be removed, no fear to have either. Ren'Py have the strongest and longest backward compatibility you can imagine. Everything that existed in the 6.0 version is still available 15 years later. I never tested a version below the 6.0, but even in the 8.0.3, "common/00compat.rpy" cover the 5.1.1 (April 2006), so I guess that the effective backward compatibility goes at least down to this version.

 

[MidnightArrow]

I agree. But by it being removed at any time, I'd think that would demand an update of Ren'py itself, no? Which would essentially mean updating in the middle of a project, which isn't recommended for this reason.

The Ren'py front page advertises "We understand that games can take months and years to finish, and try to make sure you can move to newer versions of Ren'Py without major changes."

You probably shouldn't upgrade mid-production, but PyTom says it's not a problem if you do. (Like if you need bugfixes for some other part of your project.) But I'd imagine a statement like that is contingent on the user sticking to the public API. Documentation is like a contract between you and the developers on what functions can be safely called (although Ren'py's documentation is pretty terrible at that). If you ignore it, you're breaching the contract and the program may not work as advertised.

 

[MidnightArrow]

As for the risk for it to be removed, no fear to have either. Ren'Py have the strongest and longest backward compatibility you can imagine. Everything that existed in the 6.0 version is still available 15 years later. I never tested a version below the 6.0, but even in the 8.0.3, "common/00compat.rpy" cover the 5.1.1 (April 2006), so I guess that the effective backward compatibility goes at least down to this version.

That doesn't really mean anything though. Blender's particle system code is from 2008, and they've kept it even though it sucks because they needed to lay the groundwork for the geometry nodes system to replace it. Once simulation nodes are stable, that shit is getting thrown in the garbage.

Iirc PyTom is in the middle of porting everything in Ren'py to a new OpenGL model-based renderer. So there's clearly going to be some extensive architecture changes coming. Unless you have a statement from him to the contrary, he may decide to overhaul everything and chuck all the legacy code in the garbage while he's at it, especially if the page documenting them opens with a paragraph stating "These are deprecated, don't use them."

 

[gojira667]

I would also downscale the actual image to begin with. Then you could apply a very light sharpening pass as well.

No love for Transform()?

image picture_1 = Transform("pic_1", fit = "scale-down", xsize = 1920)

Now I didn't look to see what the difference might be or how one might choose the interpolation. You can also use zoom with it if that's your bag...

 

[anne O'nymous]

That doesn't really mean anything though.

Hmm, let's see...

PyTom past two years porting Ren'Py to Python 3.x, while in the same time partly refactoring it. But codes like im.Scale would sill be here just because...

Yeah, it totally make sense.

Unless you have a statement from him to the contrary, he may decide to overhaul everything and chuck all the legacy code in the garbage while he's at it, especially if the page documenting them opens with a paragraph stating "These are deprecated, don't use them."

There's surely more than one statement from him saying the contrary, but there's no need for such thing, just looking at Ren'Py's history is enough.

By example, when he introduced the Screen Language 2, he refactored the whole original Screen Language, for it to still be usable while now branching to the newly write code. And he goes as far as including an interface to the original Screen Language for any SL2 features that he added along the time.
He decided last year to stop doing this inclusion, yet the whole original Screen Language is still present in the 8.x branch. And there's absolutely no other reason behind this than the backward compatibility. The original Screen Language can only be used in pure Python code, and all those codes have to be refactored to works with the 8.x branch. It would have been the perfect moment to drop all this.
Or, since one example will not be enough for you, there's also the cookbook, explicitly said as depreciated and obsolete since now near to 10 years, and for which all codes are still working perfectly fine.
And there's also the whole "00compat.rpy" and "00obsoltete.rpy" files, both still present in the 8.x branch. Once again, since the branch 8.x is officially a refactoring of Ren'Py, and explicitly presented as being partly incompatible due to the change needed in any Python code in your game, it would have been the perfect moment to drop this.

"Beware, if you switch to the 8.x branch, you have to firstly refactor your code for it to be compatible with the new way Ren'Py works"... There's not a single valid reason, except backward compatibility, to limit this in the Python code, and not make it apply to all the code of your game, including things likes the clicked property that nobody used since more than a decade.
The legacy is already partly broken, it could have been totally broken. Yet it isn't...