[not a bug, but finding that out was very interesting]

[Ayutac]

[oldtitle]Very buggy screen/Ren'Py/Python lang. behaviour discovered: impossible label jump[/oldtitle]

Subject: On screen Menu button with Text History error

:| :| :|
Seems like you did not understand what I said at all. :cry:
I am talking about how changing the screen's name to "_game_menu_text_history" won't help you fix the issue since that need to be a label name.
...
Here is a way to fix it. Change the screen's name back to "text_history" just like how the original did it. Then add this somewhere:

Code: Select all

label _game_menu_text_history:
    call screen text_history
    return

Then it should work. Not exactly the most elegant solution, but it involve least amount of work you need to do to fix it.

Since I was using the search function of the forum, I came to this solution (screen's inventory and label's callInventory) and with

Code: Select all

$ renpy.call(callInventory)

something went very wrong. I later discovered

Code: Select all

$ renpy.call_screen(inventory)

because I found it the wiki and replaced the code.

However, the error still exists and I really, really can't think of why. So maybe PyTom or someone else would like to have a look at it (attachment). I tried to remove as much from the project as I could without breaking the interesting part.

So here's what you do:
1. Start the game
2. Let the character sleep, then leave your apartment and go into Misty's
3. select "take her stuff", then select "back"
4. You'll get another menu WHICH IS NOT SUPPOSED TO HAPPEN!

Codewise: Through there are some files (take them as CC-BY-NC-SA licenced), because I had to bring the core data with it, the interesting ones cut down to 3: navigation.rpy, where we can move inside the hotel (you're not supposed to leave the hotel), screens.rpy where the go-around and inventory are implemented and girlRoom.rpy, where stuff happens. The critical lines in the latter are 91 and 102.

I triple checked inventory and girlRoom, I see NO WAY how the program could jump to roomGirlInsideOkay instead of ...Empty. No. Way. What is this?


Oh wait, attachment is not possible. Here you go: https://www.dropbox.com/s/1tnlikcfeocy0 ... %20copy.7z

EDIT: By the way, if you get the error message "THIS IS NOT SUPPOSED TO HAPPEN" (or something like that), I would be very glad if you find out what triggers it (apart from where I coded this message in item.rpy). I can't understand why the defaultCharacter would change

EDIT: just discovered a typo. it should be "sleep in her bed", not "sleep in her bad" xD

[PyTom]

So here's what you do:
1. Start the game
2. Let the character sleep, then leave your apartment and go into Misty's
3. select "take her stuff", then select "back"
4. You'll get another menu WHICH IS NOT SUPPOSED TO HAPPEN!

I'm not able to repeat this. I don't get the choice to "take her stuff" when in Misty's apartment.

[xela]

(I am going to resist the temptation to point out obvious programming flows since I have quite a few myself...)

Otherwise:

RenPy works exactly as it is advertised in the documentation...

and changing:

Code: Select all

renpy.call('callInventory')

to

Code: Select all

renpy.call_screen("inventory")

did fix both issues. (even if you claim that you've tried it and it didn't) <-- some bs I wrote...

[Ayutac]

I'm not able to repeat this. I don't get the choice to "take her stuff" when in Misty's apartment.

What? But it HAS TO! This is even buggier than I thought. I admit I zipped the file 2 times because first I missed a line. But I only uploaded the second one. I just downloaded it and unpacked it, all still the same.

Make sure line 233 of scripty.rpy reads

Code: Select all

        tournamentDays[iCharMisty] += [1] ## because her file was deleted

(But it should! I just red it out from the 7z I downloaded.)

That ensures that Misty is away (used in lines 24/25 in girlRoom.rpy)

Code: Select all

        if day in tournamentDays[roomOfGirl]:
            eRoomGP = False

which leads to the desired code position a few lines down

Code: Select all

        if eRoomAccess and not eRoomGP:
            narrator("You open the door of " + girllist[roomOfGirl].NameS + 
                " apartment. She isn't there.")
            renpy.jump('roomGirlInsideEmpty')

And there we get the menu already!

eRoomAccess was made true in line 18ff.

Code: Select all

        if inventory[len(inventory)-len(girllist)+roomOfGirl].hasWithD() or (
            inventory[iItemMasterKey].hasWithD()):
            eRoomAccess = True

because at the end of script.rpy the player gets the Master Key.
Seriously, how can you not reach that part? I fail to see the error in my coding, and believe me, I'm trying.

A method that may work to get to the original problem is to jump to roomGirlInsideEmpty on an earlier point, e.g. change

Code: Select all

            jump hotelfloor

in line 118 in navigation.rpy to

Code: Select all

            $ roomOfGirl = 0
            jump roomGirlInsideEmpty

On my system, problem keeps happening even then. But you should at least reach the first menu!
Deleting persistent data only made the music loader (of course it did).

RenPy works exactly as it is advertised in the documentation...

That's not the point here. If I would believe this would be a very exotic mistake, I would have kept it to myself, but I think the error might come from the combination of python Ren'Py and screen language, which could lead to other errors for other people in the future. I think it could be something importat. Bugs should be fixed.

(I am going to resist the temptation to point out obvious programming flows since I have quite a few myself...)

[/quote]Please enlighten me per PM, I would like to improve myself.

[xela]

I'm not able to repeat this. I don't get the choice to "take her stuff" when in Misty's apartment.

What? But it HAS TO!

It worked for me perfectly... I could follow given instructions on how to get to the problem in the game and in code without issues.

RenPy works exactly as it is advertised in the documentation...

That's not the point here. If I would believe this would be a very exotic mistake, I would have kept it to myself, but I think the error might come from the combination of python Ren'Py and screen language, which could lead to other errors for other people in the future. I think it could be something importat. Bugs should be fixed.

That's exactly the point...

The way it is coded in your dropbox version, game calls Inventory label from the middle of python statement in Empty label, then it calls the inventory screen, after that you obviously expect it to return to the Empty label and start from where it left off. That however is not possible because if you read RenPy documentation:

renpy.call(label, *args, **kwargs)

Causes the current Ren'Py statement to terminate, and a jump to a label to occur. When the jump returns, control will be passed to the statement following the current statement.

call has terminated previous statement, that statement is your entire label, it starts with

Code: Select all

python:

on line 69. What occurs after that is simply another expected RenPy behavior, since Empty label is skipped, game jumps to the following label "Okay", it never jumped to "Bad", I don't know where you got that idea from.

The "It Should Never Happen" error occurred because character index was never reset as Python statement in Empty was terminated prematurely.

(I am going to resist the temptation to point out obvious programming flows since I have quite a few myself...)

Please enlighten me per PM, I would like to improve myself.

Might be more fruitful to read:

http://python.net/~goodger/projects/pyc ... ndout.html
http://www.python.org/dev/peps/pep-0008/
http://www.python.org/dev/peps/pep-0020/
and something on OOP

than reading anything I might say, but I can always PM you (as I love b!tching about code other wrote since so many people complain about mine )


PS: I didn't understand from your front post that issue was fixed on using renpy.call_screen() function

[Ayutac]

PS: I didn't understand from your front post that issue was fixed on using renpy.call_screen() function :(

No problem.

it never jumped to "Bad", I don't know where you got that idea from

And that was my mistake.

The way it is coded in your dropbox version, game calls Inventory label from the middle of python statement in Empty label, then it calls the inventory screen, after that you obviously expect it to return to the Empty label and start from where it left off. That however is not possible because if you read RenPy documentation:

renpy.call(label, *args, **kwargs)

Causes the current Ren'Py statement to terminate, and a jump to a label to occur. When the jump returns, control will be passed to the statement following the current statement.

call has terminated previous statement, that statement is your entire label, it starts with

Code: Select all

python:

on line 69. What occurs after that is simply another expected RenPy behavior, since Empty label is skipped, game jumps to the following label "Okay", it never jumped to "Bad", I don't know where you got that idea from.

Okay... I admit that I had to read these lines carefully to understand them. If you're right (and your argument sounds reasonable), my mistake lies in interpreting wrong what a "Ren'Py statement" is. Sooo... you're basically telling me that renpy.call(labelname) is in fact NOT equivalent to a method call. Because that's what I thought. That's why I wrote "If" two sentences before: I can see your theory is valid, but I don't like it because it means work... And I'm still frustrated with search functions around here, so I can't currently find out about "Ren'Py statement" and would like you (or somebody else) to explain it.

(I am going to resist the temptation to point out obvious programming flows since I have quite a few myself...)

Please enlighten me per PM, I would like to improve myself.

Might be more fruitful to read:

http://python.net/~goodger/projects/pyc ... ndout.html
http://www.python.org/dev/peps/pep-0008/
http://www.python.org/dev/peps/pep-0020/
and something on OOP

than reading anything I might say, but I can always PM you (as I love b!tching about code other wrote since so many people complain about mine :) )

I clicked on the links. I have to admit, I'm not a python but a java programmer. I only learned python for Ren'Py, through it became without a doubt my favourite scripting language. That is probably the case why you wouldn't like my variable names. I almost naturally resist when I see a for-variable named __ (as seen in your posts). But I can work this over. Besides that I would prefer you pointing my flaws out rather than reading all this stuff in the handout and ignorantly think just where in my code I wouldn't have followed it. Through the project has 3 or 4 times the code compared to this snippet.


I still want a "Ren'Py statement" confirm before "closing" this thread.

[xela]

I still want a "Ren'Py statement" confirm before "closing" this thread.

Here you go:

http://www.renpy.org/wiki/renpy/doc/ref ... y_Language

I'll go over the code and PM you some notes/thoughts tomorrow.

PS:

Sooo... you're basically telling me that renpy.call(labelname) is in fact NOT equivalent to a method call.

They're the same (call's not a method). renpy.call() is python equivalent of call statement from RenPy script...

[Ayutac]

I'm also delighted to see how easy you get to find sites. I guess my search words are not as strong as they used to be. (And I still don't like the forum search.)

Sooo... you're basically telling me that renpy.call(labelname) is in fact NOT equivalent to a method call.

They're the same (call's not a method). renpy.call() is python equivalent of call statement from RenPy script...

You missunderstood. Not "to the method/statement call", but "to a call to a method", as in

Code: Select all

python:
    nextDay()

I was asking if renpy.call does not return to the point where it was – as kinda method – called, after it was finished, and it was more of a rhetorical question, since you pretty much made that point clear.

Here you go:

http://www.renpy.org/wiki/renpy/doc/ref ... y_Language

There is no real statement definition, but the enumeration is enough, thanks. But this still doesn't proof your point, because the two calls in girlRoom.rpy are both followed by an if, which is defined as a statement in the link. If you're right, that would mean statements in python are not counted as statements for "call". While this would be still a reasonable explanation, I fail to see why that would be a wished behaviour, and so I'm concluding this circumstance IS the bug. Unless it's a feature, as only PyTom would know?

EDIT: No wait. You wrote it exits the statement it is currently in, that would be "else" or, if that doesn't count, "python", just as you wrote. In any case the next to come is the next label indeed. And with this understanding I can see this "buggy" behavior is indeed as it should be. Wow, haven't felt so slow in a while.

My question with "'if' in python is or is not statement" still stands, but the original idea is destroyed completely. At least in one point I was right: This IS important, at least for my understanding of Ren'py. Official conclusion: not a bug, but very interesting.

EDIT: v the problem wasn't Python!=Java but German!=English I guess.

[xela]

There is no real statement definition

Does this help in any way? : http://www.d.umn.edu/~gshute/java/statements.html

If I had to define what a RenPy statement was, I'd say that it's any code that can be executed from RenPy script directly, but that's my own interpretation.

My question with "'if' in python is or is not statement" still stands

"if" in python is a python statement, "if" in RenPy script is RenPy statement. Call terminates RenPy statements, in your case, it was "python:" not "if/elif/else".