General Discussion

[Xela]

I removed training dungeon from the game since we are not very likely to use it before the next release, make sure that your testing.rpy matches mine.

[DarkTl]

It does (changed 7 days ago according to db). Yet the game CTDs at the interactions screen

  File "game/library/interactions/pyt - screens - interactions.rpy", line 72, in script
    python:
  File "game/library/interactions/pyt - screens - interactions.rpy", line 133, in <module>
    for k,c in schools[TrainingDungeon.NAME].all_courses.iteritems():
KeyError: 'Training Dungeon'

[Xela]

I pushed a fix with that seconds before you posted

[Xela]

I'm afraid my push is the only one for the last 30 minutes -_-

Didn't go through for some reason, try again now.

[DarkTl]

Ohhkey, I tried image snow = Snow("content/gfx/animations/interactions/note.png", xborder=(160,277), yborder=(580,700)) to check how borders work, but got

    image snow = Snow("content/gfx/animations/interactions/note.png", xborder=(160,277), yborder=(580,700))
  File "game/library/interactions/GM - kiss.rpy", line 9, in <module>
    image snow = Snow("content/gfx/animations/interactions/note.png", xborder=(160,277), yborder=(580,700))
NameError: name 'Snow' is not defined

Was it removed from the engine or something?

[DarkTl]

Or is it not included in the engine? I'm not sure 

[Xela]

Ohhkey, I tried image snow = Snow("content/gfx/animations/interactions/note.png", xborder=(160,277), yborder=(580,700)) to check how borders work, but got Was it removed from the engine or something?

It was never a part of the engine, Snow is an addon code but we have a much better version(s). One coded by Nyaatrap and one by me.

Code: [Select]

# Image definitions for snow particles:
image snow_small = Transform("snow.png", zoom=0.5)
image snow_normal = "snow.png"
image snow_large = Transform("snow.png", zoom=1.5)
image snow_very_large = Transform("snow.png", zoom=6.0, alpha=0.7, additive=0.7)

# Definition for SnowBlossom2 particles by Nyaatrap (or at least used in his cool dress-up demo):
image snow = Fixed(
    SnowBlossom2("snow_large", 50, xspeed=(20, 50), yspeed=(100, 200), start=100, fluttering=10),
    SnowBlossom2("snow_normal", 75, xspeed=(15, 35), yspeed=(75, 150), start=100, fluttering=7),
    SnowBlossom2("snow_small", 100, xspeed=(10, 25), yspeed=(50, 100), start=100, fluttering=5))

# Definition for Snowing UDD:
image snowing = Fixed(
    Snowing("snow_small", interval=(0.1, 0.15), speed=(5.5, 7.5), slow_start=(7, (0.2, 0.3))),
    Snowing("snow_normal", interval=(0.15, 0.25), speed=(3.5, 4.5), slow_start=(7, (0.4, 0.5))),
    Snowing("snow_large", interval=(0.25, 0.35), speed=(2.5, 3.5), slow_start=(5, (0.5, 0.6))),
    Snowing("snow_very_large", interval=(2, 5), speed=(0.4, 0.8), slow_start=(20, (4, 6))))
This is how both are defined in my testing scenario but options to improve are limitless. The first variation is by Nyaatrap (Japanese dungeon crawler maker with Ren'Py, you prolly played a couple of his games), the second version is mine. Both should prolly just work in PyTFall and neither will in pure Ren'Py (if you want to test in a simple project).

[Xela]

to check how borders work,

Oh, and those prolly work differently in all cases. Nyaatraps version is based of the SnowBlossom (1st version) and you can just google that for the docs. Those do manual calculations. My versions basically used a UDD/ATL combo where calculations are done by ATL code and the class simply manages that. Doc strings can be found in our UDD file but those are fairly complex.

This sets the "boarders" in case of UDD:

Code: [Select]

            -start_pos: x, y starting positions. This expects a tuple of two elements containing either a tuple or an int each.
            -end_pos: x, y end positions. Same rule as above but in addition a dict can be used, in such a case:
                *empty dict will result in straight movement
                *a dict containing an "offset" key will offset the ending position by the value. Expects an int or a tuple of two ints. Default is (100, 200) and attempts to simulate a slight wind to the right (east).

[DarkTl]

The very first hearts portrait animation is bit too jumpy at some frames. Adding alpha channel made it look a bit better, but another options are either edit it manually or make our own with the help of particles...

[Xela]

Oki, made one last push adding an option to actually create businesses, not just to upgrade existing once. This is prolly it for the night, going to try catch some zzzs.

[Xela]

The very first hearts portrait animation is bit too jumpy at some frames. Adding alpha channel made it look a bit better, but another options are either edit it manually or make our own with the help of particles...

Again an alignment/UDD issue. This one is unexpected (by me at least), I need to check if the UDD position handing can be improved further. It should work a lot better after my last push.

Edit:

I need to check if the UDD position handing can be improved further.

Prolly figured out how to do this, but don't have the time to try it out atm.

[Xela]

I'm afraid you have to give me an example of how to pass a transformed picture with custom anchor to your overlay function. You already have seen my transform function, it's nothing special.

Yeah... so most of that alignment cr@p yesterday was my UDD's fault. It only used pos to place the displayable. And never the anchor and offset

Now everything is working marvelously, I improved the hearts "luv" thing and moved exclamation "surprised" mark to the displayable. You'll have to fix the rest of the positioning for other emotions if anything except the pos() was used to position them... sorry about that but I am fairly sure it's the last time this happens here

I've left the other mechanic cause it is still required for zoom_in/out of the portraits (because it's not really an overlay, it's the manipulation of the portrait itself and I don't want to mix them). I've also added "test_case" to the other mechanic cause it can be used to try animations without restarting the whole game (screens are updated directly so you can just reload to the same spot, UDD must remember it's last state so it is working a bit differently).

[DarkTl]

I'm gonna update chars data files soon, and I wonder how should the game handle uchars with no level in data file, such cases are definitely possible. Making them lvl 1 is too simple, perhaps they should be autoleveled in the same way as rchars.

[Xela]

I'm gonna update chars data files soon, and I wonder how should the game handle uchars with no level in data file, such cases are definitely possible. Making them lvl 1 is too simple, perhaps they should be autoleveled in the same way as rchars.

Maybe, I am not so sure about this one, my plan was to set them at level 1 if no level is provided but we can always adjust that. We may add even more fields like "day" (to add the character to gameplay), pattern (we always have really basic once but we need auto-patterns for characters), maybe more. Right now it's prolly a good idea to make sure that they just work in the game.

Same for rchars cause we'll prolly have to remove a couple of fields from there and rename at least one (attack_skill, cause it is very likely that we'll allow more than one in the future). I think this is one of the final things your should do before the beta testing part.

[DarkTl]

Huh. There is a weird behavior in the gallery. If you try to look at a portrait, the game will give you a superhuge zoomed version, much larger than the actual image.
But if you looked at a battle sprite right before it, and then switched to a portrait, it will have its normal size.