ran this through Cody ai.... how doess this look
Ridiculous, like most code wrote/corrected by AI, and I'll explain why:
Python:
screen videoHandler(videos=[], channel="movie", button_xpos=0, button_ypos=0, end_threshold=0.02):
The channel argument is half useful, half stupid:
Useful because the movie can actually be played on another channel. Having a way to address this without need to edit the screen itself isn't totally a bad idea.
But stupid because this isn't the code for an API. Therefore a dev will copy the code into his own game, and perfectly have the possibility to edit the channel at this time. This because, if a dev can possibly have a reason to not use the "movie" channel for his movies, he have no reason to use more than one channel, especially when using this screen.
A better answer would have be to add a
define MOVIE_CHANNEL = "movie" with a long comment block explaining that it need to be changed if he dev use another channel. Then use that
constant to address the channel in the screen.
Due to Ren'Py screen optimization, it will be a bit faster, and since it's Python, and for once real time, a "bit faster" is something important.
The button_xpos and button_ypos arguments are useless:
Once again because it's not an API, and also because having such important part of the User Interface that can move during the game is a really bad idea. It's the dev that must adapt its movies to the interface he designed, not the opposite.
Plus, if the button s at a place where the dev don't want it, it will be obvious the first time he test the code. Therefore he'll think about moving it.
This unlike for the movie channel, that can act as a more subtle bug if the dev don't understand what channels are for; yet, if he don't understand this, there's 99% chance that he kept the default one, and therefore that the code would works fine.
It there's position that should be added as argument, it would be for the
add statement. Here it would make sense, because the size of the movies can change from one use of the screen to another, and therefore the said
add statement would then need to be moved to keep the video centered.
The end_threshold argument is totally useless:
There's
absolutely no reasons to have another value than this one. Since Ren'Py frequency is irregular, even if the version of Ren'Py can handle a
timer with a interface lower than 0.015, and the player's computer can handle it too, the lower will be the value, the higher will be the risk to miss the end of a looped movie, and therefore for it to starts an unwanted new loop.
This while a higher value would prevent to have the "as smooth as possible" transition between the movies.
The value wasn't choose arbitrary, but because it's the most adapted and the one that should always used.
Python:
default currentMovie = None
if videos:
if currentMovie is None:
$ currentMovie = videos[currentIndex][0]
There's no need to delay the assignation, it's the opposite:
Yes, it there's no videos provided, it will trigger an error. But once again this is not an API. This error have to happen, to let the dev know that he messed something during his own tests.
It also MUST happen when someone play the game. As designed by the AI, if there's no movies, the screen will display nothing
and not return. The game will enter in an endless pause that can absolutely not be stopped by the player...
This will looks like an expected behavior during the few first seconds, then players will loose patience, close the game and never play it again. And neither the player, nor the dev, will understand why it happen, especially if the content of
videos is built dynamically, and therefore can be filled during dev's test, but not for few players who followed a rely particular path that lead to it being empty.
I.e: this week I played a game update
that limited to 2 lines of dialog. This because all the content was conditioned, and my particular play kept me out of all of it, except those two lines that where common to all contents.
The same can happen to a game using this screen, and both the player and dev NEED to explicitly know that it happened.
Python:
timer 0.01:
repeat True
# Check if the current movie is near the end
if duration > 0 and duration - end_threshold <= renpy.music.get_pos(channel) <= duration:
if currentIndex < len(videos) - 1:
# If the video doesn't loop, set switchFlag to True to wait for user input
if not videos[currentIndex][1]:
$ switchFlag = True
else:
# If the video loops, move to the next video
$ currentIndex += 1
$ currentMovie = videos[currentIndex][0]
$ duration = 0
$ switchFlag = False
else:
# If it's the last video, return from the screen
return
This is absolutely not how the timer statement works.
It's not totally impossible that a part of this code works, but it would be a pure side effect and still totally broken.
Anyway, the
return would have absolutely no effect here. Called screens return through a screen action, not through an instruction.
The original screen could have use only one timer, moving the
if inside the
timer block:
Python:
timer 0.01:
repeat True
if currentIndex < len( videos ) - 1:
action if( switchFlag and duration - 0 [...]
else:
action [...]
I voluntarily choose not to do it that way, to keep the code at an as low as possible level of complexity.
Having two different
timer being easier to understand than having a single
timer than can have two different behaviors. This will devs who have an higher knowledge regarding Ren'Py would figure by themselves that it's something they can do.
Now, to address the code itself, there's a big issue: The AI didn't understood its purpose...
Python:
# If the video doesn't loop, set switchFlag to True to wait for user input
The screen do the exact opposite, waiting for players input only when a movie loop.
And, of course, the player
must have the possibility to press the button at whatever moment when the looped video is playing. Here it's even more ridiculous because the button will only be available once in a while, during at most 0.02 second...
Knowing that the average human reaction time is 0.25 seconds, be ready to face the hardest challenge you ever had with a Ren'Py game...
Python:
# Include the /currentMovie/ video into the screen and play it.
add currentMovie xpos 100 ypos 100
# If the current video duration is unknown, cache it.
if duration == 0:
$ duration = renpy.music.get_duration(channel)
if duration is None:
$ duration = 0
This is a bug fix.
Effectively, there's risk that the video isn't yet seen as started when the code get the duration. Therefore Ren'Py would return
None, what I forgot when writing this code in the fly.
I updated my code to take count of this.
Python:
if switchFlag:
[...]
textbutton "Next" action [SetVariable("currentIndex", currentIndex + 1), SetVariable("currentMovie", videos[currentIndex + 1][0]), SetVariable("duration", 0), SetVariable("switchFlag", False)]
A bug fix and many bullshit.
I totally forgot to update
currentIndex and doing it here do no harm.
I also corrected this in my code.
But as I said above, the AI inverted the
switchFlag meaning, making the code works at the opposite of what it's intended to do.
As for the update of
currentMovie directly here, it force the movie to be changed the instant the player will click. What is, once again, the exact opposite of what the screen is intended to do.
Removed NullAction(): The redundant NullAction() calls have been removed.
It's not redundant,
If screen actions expect a
condition, a
true action, and a
false action. When there's no
true action, or no
false action, you have to explicitly tell Ren'Py that he must do nothing, and it's what
NullAction() do.
And anyway, "redundant"? Do this AI know what that word mean?
Correct currentMovie Update: The currentMovie is now updated with the current movie's path.
It have always been... It's
currentIndex that wasn't updated. To my defense, as I said I wrote the code in the fly.
Race Condition Mitigation: The code now checks if the video duration is greater than 0 before comparing it to the current playback position.
I'm pretty sure that neither humans, nor AIs, achieved yet to create videos that have a negative duration...
If the video had a negative duration, it would need to be changed immediately, to not create a black hole or destroy the universe, so the code need to not check if this duration is negative; well try AI, but it's not today that you'll end humanity.
Anyway, "Race Condition", with a Ren'Py screen? Wow, now I want to see what that AI can do as marvel with it's multi-threaded screens...
Well, two errors, for a code wrote in the fly (and presented as it) during a works break... Not too bad.
But I can sleep in peace, there's no risk for an AI to take my job before I retire.
