General Discussion

[Xela]

GM - sex.rpy

There is nothing there that cannot be indented to first indent either.

Code: [Select]

label l1:
    # code

label l2:
    # code
and

Code: [Select]

label l1:
    # code
    label l2:
        # code
are the exact same thing.

In the first case, when the label code runs out, it just goes to the label directly below it... I don't think that you can come up with a variant of this where you'd have to rewrite one line of code. All I am asking is that you indent properly and put some spacing between labels and logical groups of statement so I can read your code better and anyone can see what guidelines to follow. (If notepad++ doesn't have multi-line indent adjustment, leave it to me, it'll take too long to do this like by line).

[Alex250]

(codes) are the exact same thing.

Code: [Select]

label_loop:
    newVar = 0
    while newVar < 7
        label_action:
            # complex action
        newVar++

In this code, when I jump to label_action:
- will I reach newVar++?
- if I use newVar im my complex action, will I get en error?
- - If not, what would be its value?

Of course this code is bad, it would be better to make a function for the complex action and pass newVar as a parameter if needed. I just want to know how this would be handled.


Can I pass functions as variables? Example:

Code: [Select]

def function (self, param)
    # code

# later
object.action = function
object.action(value)


I am starting to look into the items code for Issue #95.

•Review the code
•Update auto-methods
•Update the way traits are applied (should not be per "gender", not just for instances of Girl class)
•Generalize more functions (transfer/auto and etc.)

2: What do you mean, auto-methods? methods for auto-equip?
3: If I understand correctly, Traits from items are applied to Girls only and you want to extend that to all characters, right?
4: What do you mean, generalize? Make the function handle correctly more items?

[Xela]

Code: [Select]

label_loop:
    newVar = 0
    while newVar < 7
        label_action:
            # complex action
        newVar++

In this code, when I jump to label_action:
- will I reach newVar++?
- if I use newVar im my complex action, will I get en error?
- - If not, what would be its value?

Of course this code is bad, it would be better to make a function for the complex action and pass newVar as a parameter if needed. I just want to know how this would be handled.

I am not sure, my guess would be an error because newVar is defined prior to label. Ren'Py is not meant to work in the manner, all labels should be declared on first indent, they can be called if they need to be reusable, it's also possible to pass arguments to them similar to how those are passed to function. It's all in the section of Ren'Py Docs on labels.

Some notes:

1) In Python, var names are declared lowercase (Looks at the PEP in previous post).
2) new_var += 1
3) That is kewl for Ren'Py script, but when you're in pure python:

Code: [Select]

python:
    for i in xrange(7):
        # complex action

Can I pass functions as variables? Example:

Code: [Select]

def function (self, param)
    # code

# later
object.action = function
object.action(value)


I never tried, prolly not because I've seen complex binding methods coded elsewhere, you can always give it a try.

I am starting to look into the items code for Issue #95.2: What do you mean, auto-methods? methods for auto-equip?
3: If I understand correctly, Traits from items are applied to Girls only and you want to extend that to all characters, right?
4: What do you mean, generalize? Make the function handle correctly more items?

2) Auto-Equip and Auto Buy. In order to get those right, class (base) traits need to be properly integrated first... Maybe the methods themselves should also be simplified. This is a pretty complex issue... with lots of confusing code.
3) I think that I've already did. All traits need to be tagged with "female"/"male" sexes, right now they default to "unisex".
4) Exactly that, but I've done that as well I believe. I have put quite a bit of time into this issue back when I was fixing new Equipment screen.

[DarkTl]

Traits base also changed quite a lot since then. For example, classes should be taken into account for autoequip.
Good and bad traits fields are much rarer than in the beginning. And items have type fields that could help too.

[DarkTl]

Let's talk about tags substitution again. Today I'm working on that huge sex scene script (which is very simple to review  ), and once again look at huge checks that I had to come up with to make sure we show the best possible picture. How should it really work:
Partner_hidden logic:
1) If we use partner_hidden, it should have greater priority than location. Ie if we don't have partner_hidden+wildness, and we don't have that combination, we should try to show partner_hidden+simple_bg OR partner_hidden+no_bg.

2) If there are NO partner_hidden pictures with proper action and simple/no bg, then we try to show after_sex instead with proper location, or simple bg/no bg if there is no a proper location picture.

3) If we don't have even them, we have no choice but ignore partner_hidden tag, and show best possible pictures without it.
Location and actions logic:
1) If we don't have needed location, we should try to show simple_bg OR no_bg with needed actions.

2) For actions that don't have a picture (usually foot and handjob, but there could be more for rare chars) we show after_sex with needed location instead.

3) If there are no perfect location pictures, or even simple_bg/no_bg pictures, we should try to show after_sex with needed location, and if we don't have them, after_sex + no_bg/simple_bg.

5) Finally, if we don't have even pictures from 3),  we show closest possible location, ie if we have indoors+living room+anal, let's try to show indoors+anal at very least.
This is complex as hell, but it should provide the best possible sex picture. Currently function that does it is far from showing the best possible one.

[CherryWood]

A thing to consider is that we only need to check for available pictures once per girl per gameplay, cause those don't change. It would be wasteful to do that in every case again and again if that would be a part of show function somehow...

[Xela]

Are you asking if that is a sound concept or do you want me to write a func for it?

a part of show function somehow...

I'd suggest a separate function, show method is getting too long and confusing.

[DarkTl]

It is a working concept of a separate function for showing sex pictures that I tested for some time using sex scenes. It gives much better results than usual showing functions.
I'd try to write it myself, but it might be used everywhere, not only during interactions. So you probably should do it to make it as fast as possible.

Eventually I removed some parts to keep interactions file clean, because even a short version of checks is about 250 long lines. And even it gives much better results than usual simple showing.

[CherryWood]

I don't think I ever used no_bg tag... But I have a lot of pics with just outdoor tag, those that only have sky on them. They're used in girlmeets atm.


I also have a lot of profile pics without mood, will those work?

[DarkTl]

Good no_bg pics are very rare, but still exist, I use them sometimes. I don't cut background on purpose of course, I just use them if I can find them.

Profile pics without mood might be unavailable in the game, since the game already looks for mood tags based on character joy. I can tag mood myself if you are unsure how to tag them.

[CherryWood]

Profile pics without mood might be unavailable in the game, since the game already looks for mood tags based on character joy.

Wouldn't that mean that all other expressions like confident, shy, suggestive etc. are out too?

If that's true for standard girl profile pics, then It kinda bothers me to limit the selection this much. I think we should only exclude unsuitable moods (no "sad" pics when joy is high) there.
This joy-mood selection seems great for girl list portraits though.

[DarkTl]

Other expressions will require more advanced, flags-based system in addition to joy. But pictures without emotions are difficult to use no matter the system.

[Xela]

I think we should just have a func that creates required amount of perfect scenarios as lists, searches them with has_image method and returns the show if has_image pays off. Otherwise it should use normal lookup process that is the best suited.

[DarkTl]

Normal lookup process is far from perfect too. If there is no a perfect match, it only returns picture with two required tags. It's not useful enough without additional checks.

Ideally, it should try to return as many correct tags as possible, starting from first tags. Ie if there is no a picture with (tag1, tag2, tag3, tag4), it should try to return (tag1, tag2, tag3), then (tag1, tag2), then (tag1).

[Xela]

Ideally, it should try to return as many correct tags as possible, starting from first tags. Ie if there is no a picture with (tag1, tag2, tag3, tag4), it should try to return (tag1, tag2, tag3), then (tag1, tag2), then (tag1).

It does work like that.

Normal lookup should be the last resort for the func.