General Discussion

[Xela]

Let me know what you think of em..

They are awesome!

No items, we do not have a system that matches pictures to equipped items and that would be too much stuff to render anyway.

===
I just pushed small fixes of typos to interactions. They are really good!

[DarkTl]

Like I said, there are no conditions for sex scene yet, anyone will agree. Because conditions are being a lover or have super high disposition, that's bad for testing.

Also you forgot to reset the last pic to GM picture.

Nope, I just wasn't sure how to do it because I don't know what kind of images GMs use now.

Let me know what you think of em..

They actually look very good! I don't think we need a better quality.

[Xela]

Nope, I just wasn't sure how to do it because I don't know what kind of images GMs use now.

I'll look into it, img_generate() method was supposed to be used just once, then a restore_img() should have been called to return to original and the process repeated.

Since you took different approach, we need a different setup. Either something to memorize the initial image or jump back to the original label resetting everything.

[Xela]

BTW: So far I am loving GitHub/GitExtensions

[lamoli]

They are awesome!

No items, we do not have a system that matches pictures to equipped items and that would be too much stuff to render anyway.

===
I just pushed small fixes of typos to interactions. They are really good!

Hmm i was planning on making all the wearable in game items but for jewelry i might only do a rough shape of em ( will save a lot of time then ill make the exact replica later on ).. with this we might be able to do a dress-up doll equipment upgrade later on.. but it will bugs me greatly if i dont have all the wearable in game items in the renders as its 1 of the goal of this system.. ( any pose you might think of or need for new action that was just implemented or new outfits in either dress-up doll inventory as rendered pics of the item while the rendered item will be shown on the girl in the background.. and also if the item is equipped it will be shown in the action render.. )

It might take some time but end result will be amazing and even if you dont want the full dress-up system.. i might come with a pytfall mod to do it later on..

[Xela]

I did not say that we do not want one, I said that we do not have one

It's just that Otherworld had a somewhat similar system without that big of a merit... maybe you can single out the best matches for closing and render those instead of all options.

[lamoli]

I did not say that we do not want one, I said that we do not have one

It's just that Otherworld had a somewhat similar system without that big of a merit... maybe you can single out the best matches for closing and render those instead of all options.

Yeah i liked the Otherworld system but it was so limited and making new stuff was too hard.. ( if the shape of the body changed clothes woulnd adapt unless you v made lots of picture to adapt to all witch was a waist of time ) while with my system you make the 3d clothes and you will get ( the picture of the item, the wearable item on the girl in equipment screen and the item on the action you v chosen .. only 1 click to render all that as iv made templates files to do it really fast.. and best of all the clothes will adapt to any body poses/types on their own and once they are done ill add morphs to them so you could open them.. like open a blouse and strip it and so on.

Also im ready to make animations.. but single pictures / in game wearable items will come first.

[Xela]

Nope, I just wasn't sure how to do it because I don't know what kind of images GMs use now.

Ok, I looked over the code and there are two solutions:

1) Do the proper thing, instead of using pytfall.gm.generate() in new interactions and girls meets, use the more appropriate pytfall.gm.set_img() (*Same parameters). This way you can use the original image from cache when you go back to whereever you came from.

2) Finish the interaction after sex mode completely with pytfall.gm.end() But I think this is the lesser option.

- I will rename reassign pytfall.gm to gm because the latter was a sh!tty idea.
- I will adapt sex interactions to the new code, test it and push.

[DarkTl]

Xela, ignore everything that goes after my interactive sex scene, I mean those single old sex options. I noticed that you fixed some things there, but I will rewrite them too, so it's not a good idea to make them work now 

[Xela]

Xela, ignore everything that goes after my interactive sex scene, I mean those single old sex options. I noticed that you fixed some things there, but I will rewrite them too, so it's not a good idea to make them work now 

I changed some crap there as well... I don't remember what so I'll leave that as it is.

Do we need separate labels for interactions and gm sex options? Seems absurd, redundant and very hard to maintain

I fixed Gm code a bit, gonna test it and if everything is ok, push.

VERY IMPORTANT NOTE(s):

I will rename some of the gm methods!

gm.generate_img()

Should be used once upon entering new location where it is sensible to change the image! This will write to cache so we know what image to fall back to when the interaction ends and we go back to whereever we came from!

gm.set_img()

This just sets old image to a new one!

===
Try to always put a space in python oneliners (for code readability).

===

Code: [Select]

$ chr.set_flag("forced", value="false")
This line is not useful, in Python any string except for empty string will return True! So it should be: $ chr.set_flag("forced", value=False). Also consider using better flags like "interactions_sex_forced" because if someone calls all flags in the console, he's have no idea what this refers to.

You can also use 1 and 0, I even think it would be a few nanoseconds faster

===
Same thing counts for label names. You're using very plain label names for specific purposes, it's a horrible practice.

===
If you are commenting things out please try to do it with:

Code: [Select]

    # codeline
and not:

Code: [Select]

#    codeline
My editor hates that and it makes my life miserable I strongly suggest checking out JEdit, it's quire good.

===
Maybe also add some comments/spaces between logical codebits. It's not a requirement but would be nice to have.

*I fixed just the sex interactions (partly), flags and maybe some other stuff is still off.
Going to push that and the gm fixes.

[DarkTl]

This line is not useful, in Python any string except for empty string will return True! So it should be: $ chr.set_flag("forced", value=False).

But then I check it like

if chr.flag("forced") == "true"

Are you telling me it still will return true if the flag is "false"?! 

Also, initially I wanted to use true and false, ie boolean values. It gives me the error that it does not know what is it when I checked the flag.

that and it makes my life miserable I strongly suggest checking out JEdit, it's quire good.

Oh? It cannot handle tabulation in the comments, yet you suggest it?

[Xela]

But then I check it like Are you telling me it still will return true if the flag is "false"?! 

Also, initially I wanted to use true and false, ie boolean values. It gives me the error that it does not know what is it when I checked the flag.

No, that is fine. Still a weird and unnecessary practice.

The latter should not happen, what error do you get?

*Edit:
Basically:

Code: [Select]

chr.set_flag("flag", True)

Code: [Select]

if chr.flag("flag"):
    # Do something...
Is enough.

Code: [Select]

if chr.flag("flag") == True:
    # Do something...
is perfectly fine, it is redundant. If it returns True, code will run, if not (any kind of False is returned), it will go to the next logical statement.

Oh? It cannot handle tabulation in the comments, yet you suggest it?

Yes

It has a good syntax highlighting for Ren'Py.

Also, it's not that it cannot handle it, when collapsing logical code, it will break the collapse on these markers. Also original macro for commenting out it comes with does not work with this setup, although it does it with empty lines... now that I write this, it seems kinda offbase, I'll look for better macros in automatic updater.

[DarkTl]

Do we need separate labels for interactions and gm sex options? Seems absurd, redundant and very hard to maintain

I can tell that some of the labels should be used in both GMs and interactions, while others only in one of the places. Current system supports it.

We need conditions for buttons in gui though. When for example warrior characters have sparring button (leading to BE), while others don't have such a button. Or SIW characters have option to hire them for sex, while others don't.

It has a good syntax highlighting for Ren'Py.

Notepad++ has it for almost any language, including python + you can tweak it freely.

[Xela]

I can tell that some of the labels should be used in both GMs and interactions, while others only in one of the places. Current system supports it.

We need conditions for buttons in gui though. When for example warrior characters have sparring button (leading to BE), while others don't have such a button. Or SIW characters have option to hire them for sex, while others don't.

Oki.

Can you elaborate on the second issue?

Notepad++ has it for almost any language, including python + you can tweak it freely.

Oki, I am not going to start an editor debate, to each his own. Just please try to keep to given guidelines.


*I've edited my previous post.
**I am working on friends/lovers. We should add enemies and rivals I think when that is sensible. For now I'll just add the former two to wherever sensible.

[DarkTl]

Elaborate? Not sure how you can elaborate something like that 
There are buttons in screen rpy that are tied to labels in interactions rpy. There should be option to give conditions for them, pretty much like you can do it for menus.

"Option 1":
....
"Option 2" if n>m:
....

I don't really see any other way. I cannot use checks in interactions the way that hire for sex option will not look out of place for managers. So it simply should be hidden for everyone but SIWs.