General Discussion

[Xela]

Portraits animations are a very promising way to enliven all types of lines and replace missing portraits. Too bad default renpy animation functions don't support half of their methods...

Which are what? I doubt that there is something that cannot be done in Ren'Py on UDD level but that usually requires a lot of effort. But there is always a possibility that animation can be done the easy way as well, but it is not always immediately apparent.

What about yzoom and anchors?
The top edge remains in place while the bottom goes up and down thanks to repeat. While I need the bottom edge to remain in place and the top one to move up and down.
Again, this sh*t ignores anchors, I tried them everywhere I could, even inside linear itself 

Code: [Select]

transform newzoom():
    pos (200, 150)
    yanchor 1.0
    block:
        linear 1 yzoom 1.1
        pause 0.1
        linear 1 yzoom 0.9
        repeat
This just works for me..

[Xela]

Rchar files start withAnd then at some point we give them base races, ieThat leads to If I remove "race": "Digital Android", everything works.

Meanwhile uchars use race line too, and work flawlessly.

I fixed it but this is a bit off. For unique chars:

race = Trait.
full_race = Any String.

It's been like that for a while so I did the same for the rchars to be consistent, you can just mass-rename it everywhere.

[DarkTl]

Which are what? I doubt that there is something that cannot be done in Ren'Py on UDD level but that usually requires a lot of effort. But there is always a possibility that animation can be done the easy way as well, but it is not always immediately apparent.

I mean xaround and yaround, mentioned by PyTom himself (!). They are supposed to be an easy way to rotate stuff around any point, but nope, they do nothing.

I got it (probably), my mistake was in using clumsy circles statement while angle should have been used

It's not entirely reliable. Given enough time, rotation desynchronizes for some pictures, and the image begins to move in circles with gradually increasing radius.

It's probably easier to find or make another animation than do it via renpy...

[Xela]

I mean xaround and yaround, mentioned by PyTom himself (!). They are supposed to be an easy way to rotate stuff around any point, but nope, they do nothing.

around
    type: (position, position)
    default: (0.0, 0.0)
    If not None, specifies the polar coordinate center, relative to the upper-left of the containing area. Setting the center using this allows for circular motion in position mode.

The do what the docs say...

It's not entirely reliable. Given enough time, rotation desynchronizes for some pictures, and the image begins to move in circles with gradually increasing radius.

LoL

Ok... it may be a case but the "LoL" refers to me testing that code with two Solids while falling asleep yesterday and forgetting to close testing case. It was still perfect when I woke up today. It's almost 100% an error in the image you want to animate. I did have the same issue thought... with a very complex case, long time ago. Don't recall if I found a fix for it but there is a lot that can be tried there.

It's probably easier to find or make another animation than do it via renpy...

Could be the case, I still don't really know what you're doing...

[DarkTl]

Code: [Select]

transform newzoom():
    pos (200, 150)
    yanchor 1.0
    block:
        linear 1 yzoom 1.1
        pause 0.1
        linear 1 yzoom 0.9
        repeat
This just works for me..

You can freely delete yanchor 1.0 and it will do just the same. That's the problem, all animations seem to ignore manual anchors and use only default ones. While I need non default ones 

[DarkTl]

Here's what yzoom does. That's what I need. See?

[Xela]

You can freely delete yanchor 1.0 and it will do just the same. That's the problem, all animations seem to ignore manual anchors and use only default ones. While I need non default ones 

Does anyone consult the good, old Doc? Like ever...

I was about to write the above, but when going for the link, noticed that it's not mentioned there You need to use floats, like I have in my example. In case of ints, Ren'Py will use position, in case of floats, it will interpolate the coords based on the dimensions of the outer container (size of the displayable in this case). So at anchor .0 (you don't need to write 0.0 in Python) and yzoom: bottom will move. With .5, both bottom and top will "move" (outward movement from center) and with 1.0 the top will be moving.

==>
Can I close #107? Or are there still issues?

[Xela]

Does anyone consult the good, old Doc? Like ever...

I was about to write the above, but when going for the link, noticed that it's not mentioned there

Or actually, it is, but it assumes that you gonna read the whole thing, long ago it was mentioned on per case basis, I am 100% sure of that...

[DarkTl]

Can I close #107? Or are there still issues?

It also assumes that random chars should have all fields that uchars have. Like level 

[DarkTl]

Does anyone consult the good, old Doc? Like ever...

The irony 

    transform interactions_surprised_tr:
        "exclamation_mark"
        pos (130, 546)
        alpha 0.6
        yanchor 1.0
        block:
            linear 1 yzoom 1.1
            pause 0.1
            linear 1 yzoom 0.9
            repeat

That's my code. I'm looking at the moving bottom atm.

[Xela]

It also assumes that random chars should have all fields that uchars have. Like level 

I wanted the game to decide levels of the random chars! Kinda racist to say that one kind of a rchar cannot start with decent stats

==>
We cannot have "ALL" the same fields Random chars assume a lot of random data while unique chars can be preset. If you have a concept different from my own, you need to lay it out so I can adjust the code.

One thing that I am concerned about with rchars atm are the combinations of Elements and Spells. Another proper stats/skills generation at level-ups. Both however should be resolved in code and are prolly too complex for JSON files, at least at this dev stage where this stuff is evolving.

[DarkTl]

I figured rchars will have randint levels, like uchars have a fixed level.

[Xela]

That's my code. I'm looking at the moving bottom atm.

Hmm... that's not normal Ren'Py behavior...

Are you using it with my DS? Because if you are, it not setup to account for anchors, just for positions

If you want those animations to be perfect, they would have to be handled on per case basis, just like zoom_out/zoom_in of the portraits.

[Xela]

I figured rchars will have randint levels, like uchars have a fixed level.

Yeah, but what for? I mean, you cannot expect level ranges to persists as new rchars are being created throughout the game. I will also need a whole bunch of rchars to have huge levels for Arena and some other stuff before the release.

I can add this np, it's just 3 lines of extra code. I just need to know what you mean it to do exactly.

[DarkTl]

Well, they should have levels when you meet them in GMs. If you want to tie them to MC level, they will become much better than uchars at higher levels.