General Discussion

[Xela]

But what if they just stand in the first row doing nothing if you take them to battle? 

Old Huntsman style At least using them as cannon fodder is not eating them alive... They can fight and use magic in BE right? It's not like me to prevent that on running level, I like setting shit up on entry whenever possible.

[DarkTl]

That requires special AI that does nothing...

They still could be unavailable at arena for example, since it's official battles. But in some places, why not?

[DarkTl]

This one  $ gm.set_img("battle", "confident", "angry") shows no image available while the character has battle picture not with confident or angry tags. I believe it tries all tags first, then first tag + one of each tags taken from the end of taglist. But if it fails, no image is not an option too, especially when we have first tag available.

[Xela]

This one  $ gm.set_img("battle", "confident", "angry") shows no image available while the character has battle picture not with confident or angry tags. I believe it tries all tags first, then first tag + one of each tags taken from the end of taglist. But if it fails, no image is not an option too, especially when we have first tag available.

I need a test case, this is something sinister Best I can tell, this should not happen...

Or at least your devlog file with a fail in it...

[DarkTl]

Uh, ok. You need my random priest pack and last push. All random chars are added by the testing rpy, so you should have the character immediately after starting the game.
Interactions - harassment, that's the testing option when MC engages in combat with a character. It won't work with slaves eventually, but atm it works with anyone.

When you try it, the game tries to show gm.set_img("battle", "confident", "angry") before battle, but fails in case of this random character.

[Xela]

When you try it, the game tries to show gm.set_img("battle", "confident", "angry") before battle, but fails in case of this random character.

What a load of BS

I hope system isn't wrecked after I removed system path, it'd be a pain to go back to it... This is not girlsmeets related, it's a global thing, gonna try and find out wtf...

Not as bad as I thought...

My main problem was with profile image not superseding default "No Image Found" (this was an error in code), I figured out why you didn't get battle pic quickly enough.

But if it fails, no image is not an option too, especially when we have first tag available.

This is a a type="first_default" lookup order you describe here, not a normal one.

Try:

Code: [Select]

gm.set_img("battle", "confident", "angry", type="first_default")
and it'll work.

If you are confident enough in your knowledge of interactions system and sure that it will not break any other lookups badly, you can make that a default for all Interactions:

Code: [Select]

        def set_img(self, *args, **kwargs):
            """Sets the image, bypassing the image cache.
            """
            kwargs["resize"] = kwargs.get("resize", self.img_size)
            self.img = self.char.show(*args, **kwargs)
You add kwargs["type"] = kwargs.get("type", "first_default") to this.

Just grab my push first!

[Xela]

Gonna take a break, had a bad night

[DarkTl]

Alright, I do

    $ gm.set_img("battle", "confident", "angry", exclude=["happy", "suggestive"], type="first_default")
    call interactions_fight_begins # angry girl's line about upcoming battle
    hide screen girl_interactions

and run battle.
Then I do

        show expression gm.bg_cache
        show screen girl_interactions
        $ gm.restore_img()
        call interactions_fight_won

And gm.restore_img() does nothing, while it should restore and show the cached one before the battle. Am I missing something?

[Xela]

Looks like it should work.

[DarkTl]

Yeah, gm.restore_img doesn't do sh*t even without messing with BE 

    $ gm.set_img("battle", "confident", "angry", exclude=["happy", "suggestive"], type="first_default")
    "test"
    $ gm.restore_img()

And image disappears.

[Xela]

Yeah.. it's that bit of code I told you to absolutely grab first before doing anything else

That's what you get from sleep deprivation. Pull and try it again, might be a fix (not sure about anything anymore).

[DarkTl]

Right... Take a good sleep and then try to fix it again, or we will run out of working functions -_-

[Xela]

Wish that I could... but that's gonna have to wait till tonight

Problem should be fixed now. I don't remember why those unused funcs were written but we prolly should not allow automatic overwrites of cache properties. If someone needs to do that, they have to access them directly, it's less confusing that way.

===>>
It should work now in either case, I've deleted all the methods that seemed unneeded.

[DarkTl]

Wish that I could... but that's gonna have to wait till tonight

I figured as much. My point still stands though, if you catch my meaning.

Those functions were not unused, the sex scene kinda used them everywhere.
I hope that nothing was broken when I mass replaced gm.generate_img with gm.set_img

[Xela]

Damn... I don't know, it wouldn't be hard to roll back the changes and restore the method. There are two fields:

1) .img = Image shown at the moment.
2) .img_cache = Image re record on entry so we know what to fall back upon if we change it.

generate img method simply overwrote cache with the img and then set img to a char.show(...) with new arguments. So yeah, if you were using cache there as an interim variable to store previous picture, behavior will be different when you restore, because you'll get the original image from start of the interaction instead of what img was when you generated a new one.

That's the kinda thing you can prolly tell better than I cause you know how those interactions work. It was a bad name and a poor practice but we can restore it, nothing bad will happen. When searching for generate img, editor found just the four commented out lines, I thought they were useless.