Sprite Position Bug -- Are other creators seeing this?

[xela]

Odd, I half expected this to fix all issues but I've been with Ren'Py for three years and Position was even before that time so I don't really know how it works It's like using ui.module instead of screens for gui, it may or even should work but not as good and with weird, difficult to fix side-effects.

[Rosstin]

It looks like the half-sprites only work with Positions that have a Y that's defined in pixels for some reason.

IE....

These still work with the half-sprites:

Code: Select all

    $farfarleft_kneeling = Transform(xpos=farfarleft_x, anchor=(0.5, 1.0), ypos = 850)
    $leftish_kneeling = Transform(xpos=leftish_x, anchor=(0.5, 1.0), ypos = 850)
    $center_kneeling = Transform(xpos=center_x, anchor=(0.5, 1.0), ypos = 850)
    $rightish_kneeling = Transform(xpos=rightish_x, anchor=(0.5, 1.0), ypos = 820)

but these no longer work:

Code: Select all

    $ centerright = Transform(xpos=centerright_x, anchor=(0.5, 1.0))
    $ rightish = Transform(xpos=rightish_x, anchor=(0.5, 1.0))
    $ rightish2 = Transform(xpos=rightish2_x, anchor=(0.5, 1.0))
    $ medright = Transform(xpos=medright_x, anchor=(0.5, 1.0))
    $ farright = Transform(xpos=farright_x, anchor=(0.5, 1.0))
    $ farfarright = Transform(xpos=farfarright_x, anchor=(0.5, 1.0))
    $ farfarfarright = Transform(xpos=farfarfarright_x, anchor=(0.5, 1.0))

(the blah_x things are just numbers like: $right_x = 990)

The way "anchor" works is different than the way the other thing worked, so the half-sprites are being displayed in some weird place.

But anyway, that's not a hard thing to fix.

[xela]

I see... Position has some odd way of calculating anchors I guess. There is a proper value for Transform, I just don't know how Position is working. You can look it up and just set proper values, there will not be a need to change anything except redefines in that case.

[Rosstin]

I don't quite understand it except that the old way I think has a different default value than the new way.

The old way was sort of unusually convenient because I was using very similar positional objects for both half-sprites and full-sprites.

I would define a floor_farleft that I used for full-sprites, and then use a part of that as just farleft for the half-sprites.

I can just define a new set of positions for the half-sprites, like... npc_farleft. Something like that.

Then I'll just line-by-line the script. I can write some regex to recognize the statements I'm looking for.

[Rosstin]

It will take me about 35 man-hours to line-by-line the script and replace all the code manually, so I'm writing Regex to do it

Now I'm wondering if it will take 35 hrs to write the Regex

[Onishion]

The more I play with ATL stuff, the more I want this relatively simple (to my mind) addition to the Developer toolkit, a "frame" option for images. This would display as a colored border around the images on the screen (maybe you'd select one specific image at a time), that would show where the game considers the image boundaries to be, and also a crosshair on the image that shows the dead center of the image (which is always used for rotational axis), and a second crosshair that represents the anchor point.

Being able to turn on a toggle that shows these features visibly would save me a LOT of trial and error trying to build simple animations and position sprites.

[Rosstin]

OK, I think I completely fixed all the lingering issues.

I was able to redefine all the positional code in fx.rpy so that I don't have to edit the script in any way.

Thanks for all your help Xela.

[xela]

The more I play with ATL stuff, the more I want this relatively simple (to my mind) addition to the Developer toolkit, a "frame" option for images. This would display as a colored border around the images on the screen (maybe you'd select one specific image at a time), that would show where the game considers the image boundaries to be, and also a crosshair on the image that shows the dead center of the image (which is always used for rotational axis), and a second crosshair that represents the anchor point.

Being able to turn on a toggle that shows these features visibly would save me a LOT of trial and error trying to build simple animations and position sprites.

This is something you can easily code for yourself.

OK, I think I completely fixed all the lingering issues.

I was able to redefine all the positional code in fx.rpy so that I don't have to edit the script in any way.

Thanks for all your help Xela.

Awesome, that would have been my approach, no matter what the xanchor="center" did for the Position, it should still be possible to translate it into proper, numeric values. It looks like it's going to be an awesome game, good luck with it!

[Ryue]

One question there for the pause thing (did you try $renpy.pause(0.0001) ? that shouldn't be observable by a player.

Another thing as my concentration is a bit low I fear. Is there now a bug in the engine there or not? (as the example xela put together did not work in the end as I understood that means then there is a bug that SHOULD be fixed?)

[xela]

No... you misunderstood.

At first, we ended up talking about a design approach that Ren'Py takes with ATL where there is no "perfect" solution.

Second, after Rosstin had posted the actual code for the review, we found out that an outdated Position and Transition were used that were not relevant to the first issue discussed.

Third, I came up with a fix to replace all Position with Transforms. movein/out Transitions tend to detect that and that should have fixed the issue however it did so only partly because in a very old Position module, it was possible to do something like:

xalign: "center" and I had no idea what that means and didn't really care to find out. It looks like Rosstin figured it out and managed to adjust all definitions of sprite positioning with modern code (although still using older moving Transition which is not a big deal here or may even be proper as it looks like it cam detect Transofrms).

===>>
The bottom-line is that game developers should really use modern tools and preferable try to understand, if only in-general how they work. While the latter is not required, the former is implied... anyone is welcome to try using 6 - 8 years old tools that are still a part of Ren'Py internal code at their own peril but maintaining backwards compatibility shouldn't become a problem of Ren'Py developers when game devs insist on using outdated code in modern projects. I (and hopefully everyone in their right mind) would prefer Ren'Py Devs to focus on the future instead of the past.

[Onishion]

I don't think anyone intentionally sets out to use outdated tools, it's just that when people come in not knowing a lot, and search for examples, they tend to come across these tools in a way that works for something similar to what they want to do. The official Renpy site is riddled with cookbook examples based on this old code. I remember when I started learning the language, examples that included things like %d or whatever to show variables in dialog lines. It was only later I found out that this was no longer necessary and had to rewrite portions (thankfully small at the time).

[Rosstin]

Here's a little rant about these issues. Don't take this personally as developers. This is just my two cents. Everyone has done a great job on Renpy and it's incredible.

-=-=-NEW RANT APPROACHING-=-=-=-

I've "updated" Queen's code several times, but we have a massive script and a large number of coding team members. If the code I ask people to use is too complex, they'll give up, use something simpler instead of the functions I've written for them, or ask me to personally write all the code for them every single time they need something. I've several times 'updated' something to be 'better' and several months later I have to revert it because doing it the new way involves too many lines-of-code or something and people get pissed off and don't use it anyway. Many people who have a need to write code in the Renpy language are actively avoiding learning to code. They just want to write a script for their game and move on. I can't teach them how to use source control, let alone how to code conscientiously. They are writers, not coders. And yet, they need to use Renpy to implement their writing, and Renpy is code. So it's not always as simple as for me to just use the "best" code. I have to do my best but my people are here to write compelling stories, not learn Python or Renpy. As such, I can't always prevent people from using code snippets from the old wiki or other places like the forums. It's gonna happen. And I don't want to further widen the gap between the coders and noncoders by saying "no, don't do that." I want them to learn. I don't want to be the gatekeeper of code in my projects.

Anyway, just a perspective. It's not as obvious to others what code is obselete and what code isn't. I code games in a very large number of languages, but never a "run time" language like Python (as opposed to a "compile time" language). At the same time I've been using Renpy infrequently for 6+ years, so some things that are 'obselete' just look like normal design patterns to me. Queen At Arms was a game that had very simple needs of "show character at a place with a transition". None of our statements are more complex than that, and we still ran into a problem like this. I intentionally built Queen At Arms to use the most basic Renpy statements because I wanted it to be possible to maybe do an iOS version or overhaul things easily.

It does me no good to code the game "correctly" if my writers are too intimidated to comfortably edit every aspect of the script.

I can write my own half-baked data-driven visual-novel interpreter in any language in a few dozen man-hours (and I have-- MONSTR: Tinder For Monsters uses a crummy data-driven interpreter). The benefit of using Renpy is a) maturity of Renpy b) it's a universal language for OELVN developers and writers, it doesn't need to be explained to anyone.

I was reflecting this year, that the Editra editor is an awful dinosaur. Maybe things would have been easier if I'd forced people to use a better editor that has more modern features.

Anyway, as I personally grow as a game developer, my own path will be to work more and more professionally with people whom I expect to learn how to use Git, to always line-by-line their commits. Even my writers will have to learn these things. But I think that many Renpy game projects do not have an experienced coder and never will. So that's why you get issues like this.

[xela]

So that's why you get issues like this.

True, Ren'Py's code is kept backwards compatible so most of the older code is still available (although a lot of it was tweaked some it can work with newer stuff) and someone is bound to get knowledge/examples from some outdated source/guide.

We do not have one "general" guide to decent coding practices in Ren'Py Which is a shame... there is a lot of decent example/code-bits all over the forums though.

[PyTom]

I'll note that while this is probably a bug in Ren'Py, there is a guide for the well-supported features. The new documentation has a list of all supported names, and Position isn't in it.

http://www.renpy.org/doc/html/py-functi ... html#cap-P

AFAIK, right now Position is only documented on the wiki, which is massively obsoleted (and warns of being such).

[Rosstin]

I think a big problem with the outdated Wiki is that it's still the first thing to pop-up in Google search. When I Google a Renpy term, the outdated resource is always what's at the top of search.

For instance, I search "renpy atl" and I get this:
https://www.google.com/search?q=renpy+f ... =renpy+atl
http://www.renpy.org/wiki/renpy/doc/ref ... n_Language

Yes, there is a warning at the top but it's an easy thing to miss when people are googling things and looking them up.

Using the new documentation often feels very inconvenient when you're trying to look something up and it's missing.

Maybe you should merge the wiki and the documentation more. For instance, for articles that are the same between two wikis, put a link to the new documentation at the top of the wiki page. If there's an article that isn't quite complete in the new documentation, link that to the old wiki with a big warning.

Believe me, if I could have ordered everyone on the team an O'Reilly book on Renpy best practices I would have. (OK, now I want to see fanart of a Renpy O'Reilly book.... would the Renpy animal be Eileen? xD )