General Discussion

[Xela]

I read about issues with calls a bit at the renpy forum, and I had an impression that too many calls will result in overflowing calls stack. So you say I can call a label, inside it call another label, and as long as they all end with return there won't be a problem?

No problem, those issues were to bad code structure... it's easy to mess up with loads of calls. I messed up just with a couple at the witches shop a few years ago so I generally don't like using them for complex sequences, this however is a great way of using a called label.

They are multipurpose. Like, angry animation can be successfully used with indifferent to show displeasure that is too small to be angry. Or with angry portrait to show very strong anger.

Yeah, we've already agreed to separate them from portraits.

Well, when I tested the hearts animation, it lasted until we hide a line. I mean, I have to call it before every line if I want it to last longer. Like:
call hearts
char.say "ayy"
<animation disappears here after we click left mouse button to show the next line>
call hearts
char.say "lmao"

Probably because the engine hides its screen layer after every line.

It does no such thing as hiding screen layer on interacts but it will hide the say screen if it was normally shown, it may actually not be a bad idea to add these animations as an extension of the say screen... I'll look into that as well.

[DarkTl]

Huh.
Items_building_resources.json? Is there something I do not know? 

[Xela]

Huh.
Items_building_resources.json? Is there something I do not know? 

Someone is just following the development through a fork, that code is mine. Try to open the building screen and click on StripClub, make sure that you have my testing.rpy file or it may not work.

===
Overlay layer is cleared on every interaction... but do we actually want that? We may want to keep the emotions overlay active through multiple says. I am going to try and put it on a say screen for now. If we don't like it, we can change it later.

[DarkTl]

It's inconvenient to keep manually showing animation after every line. If possible, auto hiding should not happen.

[Xela]

Ok... so I did what made sense to me, if it is not sound, I'll change the design.

1) Emotions overlay is now shown on the say screen itself, it is always there, only not showing anything in it's default state.

2) If not apparent from the above, it needs to be put in it's default state when not used. It is done with:

Code: [Select]

$ interactions_portraits_overlay.change("default)
command. This design should be superior to showing on overlay screen with auto-hide on grounds of:

- with overlay, it is not possible to have the last animated state persist for options like scared, animation would have to be run every time, which is annoying (or more options would be needed).
- when/if required for animation to persist over multiple say statements, it would have to be called over and over again...
- On say screen version allows better degree of control/customization.

3) I've adjusted all atl instructions to make more sense/be more succinct.

4) My new UDD class called DisplayableSwitcher was used. It can do some really cool stuff like pausing/resuming animations, adjust it's state based off variable, being updated even between interactions, resetting animations and prolly some other stuff.

5) In order to pick animation:

Code: [Select]

$ interactions_portraits_overlay.change("love")
Love can be called like this, it's a repeated animation so we don't really care from which point we start.

Code: [Select]

$ interactions_portraits_overlay.change("sweat", "reset")
Sweat in the other hand has an endstate and must be called with reset, when called without in out setup (other cases may differ), it will go to it's last state.

Other animations like anger are judgement calls...

==>
I think this is it, it is a sound design, you'll never see these animations if say screen is not shown and as long as we don't forget to reset, everything will be fine.

I should prolly do one more adjustment to prevent the say screen to show this when there is no portrait... so narrator can be used without having to default it. I'll also look into merging this with portrait overwrites (I really like this concept). That way we can use it both with overwrites and this add-on overlay system.

[DarkTl]

Too bad blushing didn't worked out... I found a very decent transparent png for shy pics, but we cannot know where cheeks are, so it looked very weird in many cases 

The next step is probably zooming portraits a bit. Quick and short zooms will be useful for things like grabbing breast, and long and slow ones for hugs.

[Xela]

The next step is probably zooming portraits a bit. Quick and short zooms will be useful for things like grabbing breast, and long and slow ones for hugs.

Even if doable, it cannot be a part of an overlay since it's a whole different system.

The thing with the "per character" overlays, there are ways of getting it done but I am not sure which one is best/least amount of effort. Maybe it's not worth the effort... Maybe it is worth it to overwrite Ren'Py's control over portraits completely but it's not going to be easy, if we decide to go with it, I'll prolly have to write a whole bit of custom code for all of this to work.

==>
Edit:

Just had an idea... maybe we can pass the character object to the say screen and resolve sh!t accordingly! Might simplify a bunch of stuff that we want to do

[DarkTl]

Curious, repo now shows language details. In our case renpy is 97.3% and python is the rest...

Is it difficult to add tooltips to interaction buttons? Or you simply don't like the idea?

[Xela]

Curious, repo now shows language details. In our case renpy is 97.3% and python is the rest...

I know, it's bs by the way, we have loads more Python than that but they are prolly basing it off filename extensions and only SimPy is in .py files.

Is it difficult to add tooltips to interaction buttons? Or you simply don't like the idea?

The latter.

[Xela]

Oki, another push.

I've added slow_zoom/fast_zoom portrait overlays and made sure that overwrite are bound to characters so in VN mode with multiple chars, they would be easier to use. I may also add an options to use just the one portrait_override method for both at once if desired.

We'll still to be careful thought, before a none Char speaker says something (Like player for example or NPC and etc.), the overlay still needs to be defaulted! But the next time the character speaks, if characters mode was not reset, it will be restored.

I think that this is the best compromise so far using the least code. I'll improve upon code base as we develop during refactoring but while we're still working on this, current setup is best. Let me know if something needs to be added/fixed.

[DarkTl]

Looks like the three testing options in intimacy menu that do stuff but don't output any lines give an error now after your last screen update.

  File "game/library/interactions/pyt - screens - interactions.rpy", line 29, in script
    with dissolve
  File "game/library/screens/classes - screen_actions.rpy", line 347, in get_sensitive
    return self.menu not in pytfall.world_actions.nest
TypeError: argument of type 'NoneType' is not iterable

[Xela]

Looks like the three testing options in intimacy menu that do stuff but don't output any lines give an error now after your last screen update.

Fixed, actually that broke a few days back, not even sure why.

[Xela]

Your cool victory graphic inspired me to put some time into Arena screens. Loads there has been improved/fixed now I cleared white matter from it so it looks a bit dark but still pretty.

[Xela]

Yey. Our special characters in pretty fonts trouble should be a thing of the past! We just need to track down all places where might be a problem but Ren'Py's FontGroup thing passed it's test with flying colors so we have a dependable way of fixing it everywhere now. It should already work in say screen

===>
I am going to take a quick look at the SM screen next, take out that issue...

[DarkTl]

Is there a list of special characters that use a different font? Or on the contrary, anything but normal, common characters uses a different font?