A bug within renpy

In this forum we discuss the future of Ren'Py, both bug fixes and longer-term development. Pre-releases are announced and discussed here.
Message
Author
User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: A bug within renpy

#16 Post by xela »

firecat wrote:The idea of rpg homebrew was to give the developer options as to how they wanted to present the battle. if they desire to not have the gui for any reason then it is ok by me. This bug that im calling it, has ruin that central idea of adding new ways to use it. Yes still works as basic battle but can't do much after it, heck i dont know how much more broken i has become, the imagemap might not work anymore.
And what I am telling you is that you can do any behavior you like in Ren'Py:

- Have a large gui that remains shown on attacks as in the old game.
- Have a small gui that remains shown on attacks as in the upcoming remake.
- Have a large or small or both variants of the gui disappear on attacks.
- Have a large or small or both variants of the gui disappear or stay shown during any kind of action including the attacks (depending on type of the attack).

You have all the options as a developer! If you need help with some specific case, post the related code setup. What you described as a bug:

Code: Select all

golf = "golf.jpg"
    renpy.show("golf")
    renpy.hide("golf")
is not a bug. Even the old docstring from outdated Ren'Py wiki:
Function:

renpy.show (name, at_list=[], layer='master', what=None, zorder=0, tag=None, behind=None):

This is used to execute the show statement, adding the named image to the screen.

name - The name of the image to add to the screen. This may be a tuple of strings, or a single string. In the latter case, it is split on whitespace to make a tuple.
does not suggest that the above is supposed to work. I've never even considered using it that way, so the fact that it worked before was incidental, undocumented misfeature in the engine.

===========================================>>>
And Ren'Py evolves! We've been developing a very large game with loads of code/gui in our spare time for over 4 years, starting Summer 2012. Stuff occasionally breaks on new updates, but it is never too hard to fix as long as the core code is well structured.
Like what we're doing? Support us at:
Image

User avatar
firecat
Miko-Class Veteran
Posts: 540
Joined: Sat Oct 25, 2014 6:20 pm
Completed: The Unknowns Saga series
Projects: The Unknown Saga series
Tumblr: bigattck
Deviantart: bigattck
Skype: bigattck firecat
Soundcloud: bigattck-firecat
Contact:

Re: A bug within renpy

#17 Post by firecat »

xela wrote:
firecat wrote:The idea of rpg homebrew was to give the developer options as to how they wanted to present the battle. if they desire to not have the gui for any reason then it is ok by me. This bug that im calling it, has ruin that central idea of adding new ways to use it. Yes still works as basic battle but can't do much after it, heck i dont know how much more broken i has become, the imagemap might not work anymore.
And what I am telling you is that you can do any behavior you like in Ren'Py:

- Have a large gui that remains shown on attacks as in the old game.
- Have a small gui that remains shown on attacks as in the upcoming remake.
- Have a large or small or both variants of the gui disappear on attacks.
- Have a large or small or both variants of the gui disappear or stay shown during any kind of action including the attacks (depending on type of the attack).

You have all the options as a developer! If you need help with some specific case, post the related code setup. What you described as a bug:

Code: Select all

golf = "golf.jpg"
    renpy.show("golf")
    renpy.hide("golf")
is not a bug. Even the old docstring from outdated Ren'Py wiki:
Function:

renpy.show (name, at_list=[], layer='master', what=None, zorder=0, tag=None, behind=None):

This is used to execute the show statement, adding the named image to the screen.

name - The name of the image to add to the screen. This may be a tuple of strings, or a single string. In the latter case, it is split on whitespace to make a tuple.
does not suggest that the above is supposed to work. I've never even considered using it that way, so the fact that it worked before was incidental, undocumented misfeature in the engine.

===========================================>>>
And Ren'Py evolves! We've been developing a very large game with loads of code/gui in our spare time for over 4 years, starting Summer 2012. Stuff occasionally breaks on new updates, but it is never too hard to fix as long as the core code is well structured.
i dont think you know how broken 6.99.11, there hasn't been anything this broken in other engines, everyday i check the cookbooks to see if there is any error within them. Just these 2 months alone cause many users asking questions to simple answers which later found out were bugs from the new gui. My very own code was destroyed from the new gui and to this day we have yet to find any answers to removing the new gui without going into lengary build.

The code i worked on with Quan Dao Dong was not a fluke, we knew what the code was going to be doing and we design it to work for years to come. Only way a error got through the code was no other than the people who worked on renpy's new gui, no other explanation exists. Whoever was working on the new gui never consider the effects it brings to everyone who worked hard on their code.
Image


Image


special thanks to nantoka.main.jp and iichan_lolbot

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: A bug within renpy

#18 Post by xela »

firecat wrote:i dont think you know how broken 6.99.11, there hasn't been anything this broken in other engines, everyday i check the cookbooks to see if there is any error within them. Just these 2 months alone cause many users asking questions to simple answers which later found out were bugs from the new gui. My very own code was destroyed from the new gui and to this day we have yet to find any answers to removing the new gui without going into lengary build.
I don't know, "broken" is not a fair assessment of .11. First we were hunting for bugs before it became official release for like a month, where were all those people from cookbook back then? Second, new GUI is simply a new way to store default GUI settings and you can pick old way of storing that data.

Truth is that the game we're working on has many thousands of complex GUI code dealing with screens, UDDs, Battle Engine, default container classes, custom shapes, minigames, webm movies, dozens of ATL instructions and etc. Aside from a couple of misalignment, it all works under .11 and .12.
firecat wrote:The code i worked on with Quan Dao Dong was not a fluke, we knew what the code was going to be doing and we design it to work for years to come. Only way a error got through the code was no other than the people who worked on renpy's new gui, no other explanation exists. Whoever was working on the new gui never consider the effects it brings to everyone who worked hard on their code.
I've never seen that code so it's difficult to comment on this. I can only say that all the code we wrote for our games required only minor updates and realignments. Stuff can break between versions but PyTom is always asking for what gets broken from active developers and fixes the issues, we can't ask for more (or at least we shouldn't). Old code that isn't maintained by the respective owners gets outdates, old code between version break in UE, Unity, Java/Python/Lua/Perl and even C (although less often due to it being a very stable pl) and etc. But it's always fixable.

==============>>>
And bottomline, we can still do anything in Ren'Py .11 we could do in any previous version, if not more. There is also change log with stuff that was supposed to break, if some documented API got nuked, figure out what it is and report the issue so it can be fixed. A lot of cookbook code misuses Ren'Py's API and butchers Pythons and Ren'Pys common practices. Far from everything that is in there should have worked in the first place or is even close to sound code/advice.
Like what we're doing? Support us at:
Image

User avatar
firecat
Miko-Class Veteran
Posts: 540
Joined: Sat Oct 25, 2014 6:20 pm
Completed: The Unknowns Saga series
Projects: The Unknown Saga series
Tumblr: bigattck
Deviantart: bigattck
Skype: bigattck firecat
Soundcloud: bigattck-firecat
Contact:

Re: A bug within renpy

#19 Post by firecat »

xela wrote:
firecat wrote:i dont think you know how broken 6.99.11, there hasn't been anything this broken in other engines, everyday i check the cookbooks to see if there is any error within them. Just these 2 months alone cause many users asking questions to simple answers which later found out were bugs from the new gui. My very own code was destroyed from the new gui and to this day we have yet to find any answers to removing the new gui without going into lengary build.
I don't know, "broken" is not a fair assessment of .11. First we were hunting for bugs before it became official release for like a month, where were all those people from cookbook back then? Second, new GUI is simply a new way to store default GUI settings and you can pick old way of storing that data.

Truth is that the game we're working on has many thousands of complex GUI code dealing with screens, UDDs, Battle Engine, default container classes, custom shapes, minigames, webm movies, dozens of ATL instructions and etc. Aside from a couple of misalignment, it all works under .11 and .12.
firecat wrote:The code i worked on with Quan Dao Dong was not a fluke, we knew what the code was going to be doing and we design it to work for years to come. Only way a error got through the code was no other than the people who worked on renpy's new gui, no other explanation exists. Whoever was working on the new gui never consider the effects it brings to everyone who worked hard on their code.
I've never seen that code so it's difficult to comment on this. I can only say that all the code we wrote for our games required only minor updates and realignments. Stuff can break between versions but PyTom is always asking for what gets broken from active developers and fixes the issues, we can't ask for more (or at least we shouldn't). Old code that isn't maintained by the respective owners gets outdates, old code between version break in UE, Unity, Java/Python/Lua/Perl and even C (although less often due to it being a very stable pl) and etc. But it's always fixable.

==============>>>
And bottomline, we can still do anything in Ren'Py .11 we could do in any previous version, if not more. There is also change log with stuff that was supposed to break, if some documented API got nuked, figure out what it is and report the issue so it can be fixed. A lot of cookbook code misuses Ren'Py's API and butchers Pythons and Ren'Pys common practices. Far from everything that is in there should have worked in the first place or is even close to sound code/advice.
yes this here tells me that you have not tested anything, also you guys never tell us anything until the release. there is no way to know if you change anything in the last minute, plus the renpy github is barely readable so ya cant really help fix it without knowing where the GUI file might be, another thing about github i found is that you only made 1 contribution. don't know if you help outside it but clearly tells me that you don't spend time with the engine.

about the changelog, i already read it: https://www.renpy.org/doc/html/changelog.html

and guess what, only renpy 6.99.11 has the bugs that i am telling you about. this also includes a major bug with android build and maybe possibly Editra because now its starting to act up. these changes in 6.99.11 have started to cause problems, so i'll see if removing gui script, the new error code and having editra return back to an older version might be a fix.
Image


Image


special thanks to nantoka.main.jp and iichan_lolbot

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: A bug within renpy

#20 Post by xela »

firecat wrote: yes this here tells me that you have not tested anything, also you guys never tell us anything until the release. there is no way to know if you change anything in the last minute, plus the renpy github is barely readable so ya cant really help fix it without knowing where the GUI file might be, another thing about github i found is that you only made 1 contribution. don't know if you help outside it but clearly tells me that you don't spend time with the engine.
Not being a Ren'Py developer, I have worked with the engine for almost 5 years and know most it's code. On the testing front, I have an open soured project on GitHub that with close to 100 000 lines of code (Python, Ren'Py, JSON). There are over 150 screens, a bunch of UDDs, many python classes, drag&drop, custom click and point mapping that loads from JSON file and can handle any shapes/sizes. We also have another project with minigame like shooting range (an outdated version): https://www.youtube.com/watch?v=4wZhf3TQV6M and custom code that combines screens, python logic and ATL: https://www.youtube.com/watch?v=3bGeLccCFvs and loads of other stuff.

Loads can be tested just by running those projects and they're all working just fine under .11 and .12 as I am sure many other projects are as well.

Before every release, there is a per-release version, you do not need to grab it from GitHub, you can change update channel of your launcher to test it out. It is not possible for PyTom to test every possible combination of possible code setups so we're asked to test our sh!t and contribute by reporting bugs AND different behavior between current per-release and previous version.

New version does not come out until report in the thread don't quite down and all is fixed. There is such a thread now here for .12: viewtopic.php?f=8&t=41201
firecat wrote:and guess what, only renpy 6.99.11 has the bugs that i am telling you about. this also includes a major bug with android build and maybe possibly Editra because now its starting to act up. these changes in 6.99.11 have started to cause problems, so i'll see if removing gui script, the new error code and having editra return back to an older version might be a fix.
- I can build for Android just fine, the bug in the Q&A section is more OS related than Ren'Py but I assume it'll get fixed soon.
- No idea about Editra, if there is a bug report it.

You're reported a specific issue which you believed to be a bug, that is resolved. Otherwise there are 80 Issues on GitHub and I am sure that there are bugs in the engine, in fact I just found one that breaks Lint in my project :D My point is that there is still nothing that the engine should be able to do which .11 or .12 would prevent us from doing. It would serve everyone well if we could switch to specific bugs/issues instead of a general ".11 is broken" statement, maybe we can come up with some fixes for them...
Like what we're doing? Support us at:
Image

User avatar
firecat
Miko-Class Veteran
Posts: 540
Joined: Sat Oct 25, 2014 6:20 pm
Completed: The Unknowns Saga series
Projects: The Unknown Saga series
Tumblr: bigattck
Deviantart: bigattck
Skype: bigattck firecat
Soundcloud: bigattck-firecat
Contact:

Re: A bug within renpy

#21 Post by firecat »

xela wrote:
firecat wrote: yes this here tells me that you have not tested anything, also you guys never tell us anything until the release. there is no way to know if you change anything in the last minute, plus the renpy github is barely readable so ya cant really help fix it without knowing where the GUI file might be, another thing about github i found is that you only made 1 contribution. don't know if you help outside it but clearly tells me that you don't spend time with the engine.
Not being a Ren'Py developer, I have worked with the engine for almost 5 years and know most it's code. On the testing front, I have an open soured project on GitHub that with close to 100 000 lines of code (Python, Ren'Py, JSON). There are over 150 screens, a bunch of UDDs, many python classes, drag&drop, custom click and point mapping that loads from JSON file and can handle any shapes/sizes. We also have another project with minigame like shooting range (an outdated version): https://www.youtube.com/watch?v=4wZhf3TQV6M and custom code that combines screens, python logic and ATL: https://www.youtube.com/watch?v=3bGeLccCFvs and loads of other stuff.

Loads can be tested just by running those projects and they're all working just fine under .11 and .12 as I am sure many other projects are as well.

Before every release, there is a per-release version, you do not need to grab it from GitHub, you can change update channel of your launcher to test it out. It is not possible for PyTom to test every possible combination of possible code setups so we're asked to test our sh!t and contribute by reporting bugs AND different behavior between current per-release and previous version.

New version does not come out until report in the thread don't quite down and all is fixed. There is such a thread now here for .12: viewtopic.php?f=8&t=41201
firecat wrote:and guess what, only renpy 6.99.11 has the bugs that i am telling you about. this also includes a major bug with android build and maybe possibly Editra because now its starting to act up. these changes in 6.99.11 have started to cause problems, so i'll see if removing gui script, the new error code and having editra return back to an older version might be a fix.
- I can build for Android just fine, the bug in the Q&A section is more OS related than Ren'Py but I assume it'll get fixed soon.
- No idea about Editra, if there is a bug report it.

You're reported a specific issue which you believed to be a bug, that is resolved. Otherwise there are 80 Issues on GitHub and I am sure that there are bugs in the engine, in fact I just found one that breaks Lint in my project :D My point is that there is still nothing that the engine should be able to do which .11 or .12 would prevent us from doing. It would serve everyone well if we could switch to specific bugs/issues instead of a general ".11 is broken" statement, maybe we can come up with some fixes for them...
i dont believe you, the evidence is clear that you have no understanding of the engine. if you were really were someone who worked 5 years on renpy then a simple bug fix of the new textbox gui should been fixed but that hasn't happen, not to mention the code you give me was nothing but background which does not fix anything only adds to more problems.
Image


Image


special thanks to nantoka.main.jp and iichan_lolbot

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: A bug within renpy

#22 Post by xela »

firecat wrote:i dont believe you, the evidence is clear that you have no understanding of the engine.
You're ofcourse more than welcome to believe whatever you like :)
firecat wrote:if you were really were someone who worked 5 years on renpy then a simple bug fix of the new textbox gui should been fixed but that hasn't happen
Which bug? I am not using the new GUI in any of my projects btw, cause it offers no advantages to custom designs and I have not started any new projects since .11 was released.
firecat wrote:not to mention the code you give me was nothing but background which does not fix anything only adds to more problems.
The code I gave you explains how to put an image in screen in Ren'Py using a Python function and without binding it to internal tagging mechanism permanently. It is the correct way to do it, it has worked in every Ren'Py version for the past 5 years and I fully expect it to work for every version in the future without fail. It can be used to show not just the backgrounds but any displayable that can be shown in Ren'Py except screens which use their own functions. If you do not understand that, it may be why your code doesn't work...
Like what we're doing? Support us at:
Image

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: A bug within renpy

#23 Post by xela »

firecat wrote:The code i worked on with Quan Dao Dong was not a fluke, we knew what the code was going to be doing and we design it to work for years to come. Only way a error got through the code was no other than the people who worked on renpy's new gui, no other explanation exists. Whoever was working on the new gui never consider the effects it brings to everyone who worked hard on their code.
If you're talking about this: viewtopic.php?f=51&t=35974, it still works with new gui design perfectly, even thought you're using ancient UI module...
Like what we're doing? Support us at:
Image

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: A bug within renpy

#24 Post by xela »

firecat wrote:then a simple bug fix of the new textbox gui should been fixed but that hasn't happen
If by chance, you're talking about this:

viewtopic.php?f=8&t=41305

you've already been told that it's not a bug in the thread. Window behavior is determined by:

Code: Select all

define config.window = "auto"
variable. You can find it in options.rpy file and if you change it to:

Code: Select all

define config.window = "hide"
to get the window to disappear automatically. This behavior is also well documented and is old... faaaar older than new gui.

Alternatively, this will work too, in .11/.12 and many version before them:

Code: Select all

label start:
         
    window hide # Changes behavior set in config.
    "meow!"
    "fight or die"
   
    $ potions_left = 10
    with None
    jump fight
================================>>>
So... once again... not a bug :(
Like what we're doing? Support us at:
Image

User avatar
firecat
Miko-Class Veteran
Posts: 540
Joined: Sat Oct 25, 2014 6:20 pm
Completed: The Unknowns Saga series
Projects: The Unknown Saga series
Tumblr: bigattck
Deviantart: bigattck
Skype: bigattck firecat
Soundcloud: bigattck-firecat
Contact:

Re: A bug within renpy

#25 Post by firecat »

xela wrote: The code I gave you explains how to put an image in screen in Ren'Py using a Python function and without binding it to internal tagging mechanism permanently. It is the correct way to do it, it has worked in every Ren'Py version for the past 5 years and I fully expect it to work for every version in the future without fail. It can be used to show not just the backgrounds but any displayable that can be shown in Ren'Py except screens which use their own functions. If you do not understand that, it may be why your code doesn't work...
if i wanted a image on the screen it would be far easier to use:

Code: Select all

show image
and again im telling you the code can't do much, you can't spin it around, do animation, use screens functions or use movies with image. The rpg homebrew is old but does everything better than renpy's screens and gui functions combine.

Code: Select all

define config.window = "hide"
does work however it has bugs. clearly the toolbar can still be seen but easy fix with hiding it but that wasn't the big bug. you can't auto update using this code, this will present many problems way more then having auto stay on.

so ya its still a bug but now its becoming a bug within a bug.
Image


Image


special thanks to nantoka.main.jp and iichan_lolbot

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: A bug within renpy

#26 Post by xela »

firecat wrote: if i wanted a image on the screen it would be far easier to use:

Code: Select all

show image
I told you: "using a Python function without creating an image binding". Ren'Py script equivalent is:

Code: Select all

show expression Image("golf.jpg") as some_tag
if you bound it to a tag, your way will work.
firecat wrote: and again im telling you the code can't do much, you can't spin it around, do animation, use screens functions or use movies with image. The rpg homebrew is old but does everything better than renpy's screens and gui functions combine.
Really?:

Code: Select all

transform meow(d):
    subpixel 1
    pos (100, 100)
    d
    rotate 0
    
    linear 1.0 rotate 360
    zoom 1.0
    linear 1.0 zoom 2.0 rotate 0 pos (500, 300)
    
    around (500, 300)
    angle 0
    radius 0
    linear 1.5 counterclockwise circles 3 radius 350 zoom 1.0 rotate 360
    
    repeat
    
label start:
    $ renpy.show("meow", what=meow(Solid("F00", xysize=(100, 100))))
    # same as show expression meow as meow but in Python...
    pause
    hide meow
And there is not one damn thing that your "homebrew" can do any better than screens would. Same thing can be rewritten in screen language in 10 mins.
firecat wrote: does work however it has bugs. clearly the toolbar can still be seen but easy fix with hiding it but that wasn't the big bug. you can't auto update using this code, this will present many problems way more then having auto stay on.

so ya its still a bug but now its becoming a bug within a bug.
I don't know what this means. Post code and explain what you think it is supposed to be doing and what you believe it does wrong. There is no point in continuing this otherwise.
Like what we're doing? Support us at:
Image

User avatar
firecat
Miko-Class Veteran
Posts: 540
Joined: Sat Oct 25, 2014 6:20 pm
Completed: The Unknowns Saga series
Projects: The Unknown Saga series
Tumblr: bigattck
Deviantart: bigattck
Skype: bigattck firecat
Soundcloud: bigattck-firecat
Contact:

Re: A bug within renpy

#27 Post by firecat »

xela wrote:
firecat wrote: if i wanted a image on the screen it would be far easier to use:

Code: Select all

show image
I told you: "using a Python function without creating an image binding". Ren'Py script equivalent is:

Code: Select all

show expression Image("golf.jpg") as some_tag
if you bound it to a tag, your way will work.
firecat wrote: and again im telling you the code can't do much, you can't spin it around, do animation, use screens functions or use movies with image. The rpg homebrew is old but does everything better than renpy's screens and gui functions combine.
Really?:

Code: Select all

transform meow(d):
    subpixel 1
    pos (100, 100)
    d
    rotate 0
    
    linear 1.0 rotate 360
    zoom 1.0
    linear 1.0 zoom 2.0 rotate 0 pos (500, 300)
    
    around (500, 300)
    angle 0
    radius 0
    linear 1.5 counterclockwise circles 3 radius 350 zoom 1.0 rotate 360
    
    repeat
    
label start:
    $ renpy.show("meow", what=meow(Solid("F00", xysize=(100, 100))))
    # same as show expression meow as meow but in Python...
    pause
    hide meow
And there is not one damn thing that your "homebrew" can do any better than screens would. Same thing can be rewritten in screen language in 10 mins.
firecat wrote: does work however it has bugs. clearly the toolbar can still be seen but easy fix with hiding it but that wasn't the big bug. you can't auto update using this code, this will present many problems way more then having auto stay on.

so ya its still a bug but now its becoming a bug within a bug.
I don't know what this means. Post code and explain what you think it is supposed to be doing and what you believe it does wrong. There is no point in continuing this otherwise.
here is the whole code from volume 3 of my game, i test it on many versions and no matter what i do on it no matter how many times i copy the screen files, script or options. the engine in the new game does not accept it. The code is copied perfectly from the download page of itch.io and does work when you play it. However for some strange reason it doesn't work on new projects that i added on.

Also you got the code wrong, it should be:

Code: Select all

label start:
    
    scene cat
    
    "mewo im a cat"
    
    "not just a cat but a powerful one, come on try to hit me"
    
    show jumpcat9000:
        xpos 0.5 ypos 0.5 xanchor 0.5 yanchor 0.5
        rotate 0
        linear 4.0 rotate 360
        repeat
        
    python:
        
        heromax_HP = 1000
        hero_HP = 1000
        
        tigermax_HP = 2000
        tiger_HP = 2000
        
        extramax_HP = 9000
        extra_HP = 9000
        
        evilmax_HP = 5000
        evil_HP = 5000

        while True:
            
            stats_frame("ExtraP", 9, extra_HP, extramax_HP, xalign=0.20, yalign=0.05)
            stats_frame("Tiger", 4, tiger_HP, tigermax_HP, xalign=0.98, yalign=0.8)
            stats_frame("Hero", 1, hero_HP, heromax_HP, xalign=0.02, yalign=0.05)
            stats_frame("Evil", 5, evil_HP, evilmax_HP, xalign=0.80, yalign=0.8)
            battle("win", "lose", hero_HP, extra_HP, tiger_HP, evil_HP, xalign=0.5, yalign=0.5)
            
label win:
    
    hide jumpcat9000

    "yay"
    
    return
    
label lose:
    
    hide jumpcat9000
    
    "noo"
    
    return
As you can see this is way better and the funny part is that it can be found on Tutorial.
Attachments
script.rpy
the entire code from vol 3
(172.95 KiB) Downloaded 72 times
Image


Image


special thanks to nantoka.main.jp and iichan_lolbot

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: A bug within renpy

#28 Post by xela »

firecat wrote:As you can see this is way better and the funny part is that it can be found on Tutorial.
Not the point. You've started this thread with a supposed problem with renpy.show/renpy.hide Python functions. Then you told me that I could not animate using those functions. I have simply shown you how. There are many ways to show stuff in Ren'Py, as I've also pointed out and in this particular case using Ren'Py script (as is in your example) is smarted as it will trigger automatic image predictions.

Code: Select all

here is the whole code from volume 3 of my game, i test it on many versions and no matter what i do on it no matter how many times i copy the screen files, script or options. the engine in the new game does not accept it. The code is copied perfectly from the download page of itch.io and does work when you play it. However for some strange reason it doesn't work on new projects that i added on.
I get the obvious I/O errors due to missing resources but the code in the file is being executed seemingly without any issues. I've also deleted the texts/refs to missing resources and went straight to the minigame, it also runs perfectly fine. What problems do you have with this script, I mean in a sense: what does it do differently from your expectations or what errors you get when running it in .11 with a complete project (graphical and sound resources present)?
Like what we're doing? Support us at:
Image

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: A bug within renpy

#29 Post by xela »

I may have found your game: TheUnknownsSagaVol3.

It looks the same and it's working perfectly fine under .11 and .12. If what you are trying to do is to create a project in .11 using the New GUI design and just throw these resources into the folder, it might not work but neither is it expected to!

New GUI introduces a new approach to "thinking" about GUI design in Ren'Py but it is NOT forced on you. Much like screen language and ui. module, your minigame (battle engine) is written in older ui functions while modern way would be to write it in screen language but you are choosing not to do so and it is not forced upon you as the old way simply works.

You have created a custom GUI design using the old ways/approaches, it can be converted to work with the new GUI with a bit of effort, much like your battle engine minigame can be converted to work in screen language with a bit of effort. If you want to do either one is up to you, but keep in mind that you can still use .11 to develop your game (I do mean this game, not games in general) further, I've tested it under .11 and .12 using older theamed gui approach myself and it's all working perfectly fine.

=============================>>>
My original point stands... .11 and .12 are not broken. You code can be ran under them without any modifications to it at all! If you want to use New GUI with it, you'll have to put a bit of effort towards rewriting parts of the design but you can just keep using the (now older) theamed GUI approach and it will work under .11 much like your Battle Engine still works under it.

=============================>>>
If you are still having trouble with "window hide" and your battle engine (bug in bug as you've called it) in .11, or some other use case, post the code, it's more productive if we can see what we're talking about.
Like what we're doing? Support us at:
Image

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: A bug within renpy

#30 Post by xela »

xela wrote:with a bit of effort
(and cause you star catgirl in your game :) )

1) Create a new project in .11 and pick the New GUI design of your choice.
2) Delete script.rpy, script.rpyc, options.rpy, options.rpyc, screens.rpy and screens.rpyc assuming they exist in this new project you've created.
3) Delete options.rpy, options.rpyc, screens.rpy and screens.rpyc assuming they exist in your original project.
4) Delete cache and saves folders in your original project.
5) Copy everything that remains from your original project into the new project.
6) Add the two files attached to this post to the new project.

===========================>>>
Your saga and battle minigame should now work with the New GUI design, at least they do for me.
Attachments
screens.rpy
(38.32 KiB) Downloaded 72 times
options.rpy
(6.72 KiB) Downloaded 82 times
Like what we're doing? Support us at:
Image

Post Reply

Who is online

Users browsing this forum: No registered users