Renpy 4.8.2a Demo Crash

[Kevadu]

So I decided to try out Renpy, but when I run the included demo as soon as I select 'Start Game' it crashes dumping the following to the console:

Pygame Parachute Traceback:
File "/home/david/Project/renpy-4.8.2a/renpy/display/im.py", line 314, in load
File "run_game.py", line 70, in main
renpy.main.main(options.game)
File "/home/david/Project/renpy-4.8.2a/renpy/main.py", line 211, in main
run(restart)
File "/home/david/Project/renpy-4.8.2a/renpy/main.py", line 174, in run
game.context().run()
File "/home/david/Project/renpy-4.8.2a/renpy/execution.py", line 125, in run
node = node.execute()
File "/home/david/Project/renpy-4.8.2a/renpy/ast.py", line 463, in execute
renpy.exports.with(trans)
File "/home/david/Project/renpy-4.8.2a/renpy/exports.py", line 446, in with
suppress_overlay=not renpy.config.overlay_during_wait)
File "/home/david/Project/renpy-4.8.2a/renpy/display/core.py", line 751, in interact
repeat, rv = self.interact_core(**kwargs)
File "/home/david/Project/renpy-4.8.2a/renpy/display/core.py", line 933, in interact_core
self.display.show(root_widget, suppress_blit)
File "/home/david/Project/renpy-4.8.2a/renpy/display/core.py", line 545, in show
damage = renpy.display.render.screen_blit(surftree, self.full_redraw)
File "/home/david/Project/renpy-4.8.2a/renpy/display/render.py", line 317, in screen_blit
screen.set_clip(cliprect)
AttributeError: 'NoneType' object has no attribute 'set_clip'

The last script statement executed was on line 126 of game/script.rpy.


I haven't even modified the script at all yet, so this is during the first scene transition to Washington. I'm running Debian Linux (testing) and I have the renpy module compiled, although it did the same thing before I compiled it.

Oddly enough all the completed games I've tried out have always worked fine.

Help would be appreciated, thanks.

[Kevadu]

Well that was fast...

I just noticed that 4.8.3 was released while I was posting this and it seems to have fixed the problem. So how 'bout that...

[Megaman Z]

I just noticed that 4.8.3 was released while I was posting this and it seems to have fixed the problem. So how 'bout that...

*finishes laughing to self... NOT AT YOU!* talk about irony...


I guess we can't say you weren't using the latest version of ren'py...

[Kevadu]

So...replying to my own post again...

I should know better than to change multiple things at a time while debugging. Anyway, just for clarity sake I was also messing around with my MIDI stuff when I noticed 4.8.3 was out and decided to try it. But it appears that is was actually my mucking around with MIDI that fixed the problem and 4.8.3 didn't have anything to do with it.

It might be nice to have the program fail more gracefully in this case.

[Megaman Z]

So...replying to my own post again...

I should know better than to change multiple things at a time while debugging. Anyway, just for clarity sake I was also messing around with my MIDI stuff when I noticed 4.8.3 was out and decided to try it. But it appears that is was actually my mucking around with MIDI that fixed the problem and 4.8.3 didn't have anything to do with it.

It might be nice to have the program fail more gracefully in this case.

I've made that mistake in VisBASIC, too. you're not the only one to go down that path of traps...

(of course, I've also done a good fifty-sixty lines of code without testing and then left to wonder "WTF?" when I get a compile error. such as that "end select without select case" error I had for TOZ. speaking of which, I need to be emailing the fix for that to somebody)

[PyTom]

The problem, BTW, was that pygame returned None instead of the proper surface for the screen. I have no idea why that would be... I'll chalk it up to either transient weirdness or psyco-inspired weirdness.

I'm glad its fixed, whatever the underlying cause of the problem was.

In general, I try to handle errors that are user mistakes or things like that. But it's hard to figure out how to handle a random library glitch, or a coding error by the game designer.

[Beta]

The problem, BTW, was that pygame returned None instead of the proper surface for the screen. I have no idea why that would be... I'll chalk it up to either transient weirdness or psyco-inspired weirdness...

...or the wierd science experiments that nobody in my area (or Zeta's for that matter) understands caused it... we had a couple graphical glitches on some of our other programs and one case of BT not accepting our connect method and spewing out "Connection reset by peer", which was ultimately fixed by re-downloading the damn torrent...