General Discussion

[Xela]

Ok... so I've decided to shelf the normal logging for the fg. Instead of three separate logging systems, we'll have one stream of log objects and settle them when building reports. That should be powerful and flexible enough to get everything straight and will be simpler than maintaining three separate systems. Gonna try writing some more code for SE tonight.

[DarkTl]

Maybe it's better to show prebattle lines inside BE in the beginning of fight, if it's possible?

[Xela]

Maybe it's better to show prebattle lines inside BE in the beginning of fight, if it's possible?

Sure thing, we can even add some boasting effects or speech bubbles at some point

Present way will do for the beta. I feel like that micro stuff in a game of PyTFall's scale gets lost in general gameplay. It'd make more sense if we had a much narrower concept. If you just want to displayable the lines with a combat setup but before anyone can act, that we can do for the beta. Basically it's just moving code from label to the BE. I've made sure something along those lines was possible so we might add some responses from fighter after attacks or during scripted combat in some distant future.

[DarkTl]

You know, turns out it's pretty easy to find battle quotes from other games, and a lot of them. For attacks, for dodge, for crit hit, for spells (different depending on element).

Might be worth adding after 1.0.

[Xela]

You know, turns out it's pretty easy to find battle quotes from other games, and a lot of them. For attacks, for dodge, for crit hit, for spells (different depending on element).

Might we worth adding after 1.0.

Yeap. I think it might even be possible to make them unobtrusive, like dismissing/showing them in the same way as attack animations.

[Xela]

In the future we could also introduce a possibility of someone interfering in random harassment fights. Like other chars from the same location or town watch or just someone random.

[DarkTl]

I wrote function interactions_prebattle_line, which should return unique prebattle lines.
But it doesn't work with lines containing [character.mc_ref], throwing an error...

[Xela]

Code: [Select]

        l = len(characters)
        if len > 0:Is perfectly workable but always frowned upon in favor of simpler if characters:.

Code: [Select]

                if result:
                    character.say(result)Not really required because there should be no case where this fails cause you cover all the bases with choices. Also choice([]) is a crash so it would fail with a crash before that anyhow.

Code: [Select]

returnis not required, I don't actually remember what great "pythonistas" say on the topic (if it should be added or not for clarity and readability).

===========>>>
I've rewrote the function a little bit to my personal preference (and tested it) but I have no clue as to why your version did not work (I didn't test it). It was logically and syntactically sound, or at least I see absolutely nothing wrong with it (except styling remarks which hold no relevance to it's abilities what so ever).

[DarkTl]

  File "game/library/interactions/GM - chat.rpy", line 4, in script
    $ interactions_prebattle_line(hero.team)
  File "game/library/interactions/GM - chat.rpy", line 4, in <module>
    $ interactions_prebattle_line(hero.team)
  File "game/library/interactions/function - interactions (GM).rpy", line 323, in interactions_prebattle_line
    character.say(result)
KeyError: 'character'

Error is still there. I put 2 kuudere in hero team and and run the function for the team 1-3 times to get the error 
If you use for example impersonal chars who don't use mc_ref, you will never get errors.
 
I thought there might be problems with different values of [character.mc_ref] for different characters, resulting in incorrect lists subtractions. But even so, it shouldn't result in error. Since lines without errors never have character.mc_ref inside, I believe it causes them.

[Xela]

You're right... this may be a bug, I see not reason for Ren'Py not be able to interpolate from local scopes but I am be wrong about this. In either case, this should be fixed (somewhat (technically) poorly but reliably).

[Xela]

Ren'Py will interpolate variables found in the global store. When using a text widget in a screen, Ren'Py will also interpolate screen local variables. (This can be overridden by supplying an explicit scope argument to the Text displayable.)

Yeah, I guess that is asking for a bit too much. When in Python land, do as Python does basically we should have used Python interpolation... instead of the stupid var to global thing I did to fix this... all things considered, I think it's safe for this case...

[Xela]

Code: [Select]

                ... bla bla bla
                elif "Imouto" in character.traits:
                    lines = ["Ahaha, we'll totally beat you up!", "Behold of my amazing combat techniques, {mc_ref}! ♪"]
                ... bla bla bla
                result = random.sample(set(lines).difference(said_lines), 1)[0]
                result.format(mc_ref=character.mc_ref)
For all lines would be the proper solution I think but I didn't want to have this function for beta anyway (even if it's nice) And my sh1tty "global" thing will work even if it's not mentally sound

[DarkTl]

Even if result doesn't have mc_ref? Wouldn't it be an error then?

[Xela]

Even if result doesn't have mc_ref? Wouldn't it be an error then?

I don't think so. .format is a fairly modern method and those are usually not stupid and quite intuitive (unlike some of the crap they came up 10 years ago and removed only in Python 3+ which we don't have in Ren'Py).

Edit:
Just tested it, it's kinda half/half. It will work as long as you don't have any other {} to interpolate... like Ren'Py text tags we might want to use one day... It's an imperfection in the engine I guess, I wonder if Text("", scope=locals()) might work.

Edit 2:
The last variant does some weird crap by printing out memory address instead of the string...

[Xela]

It's an imperfection in the engine I guess

Yeap... it's an easy fixable imperfection. At least I cannot see a way to solve this without writing one or two lines of custom code for it In either case, what we have now will work.