General Discussion

[DarkTl]

Yup, they are up to date. You can ignore traits_testing and traits_training, they are for testing and using in special cases. Also traits_class_mobs and traits_class jsons, they contain classes traits which will be handled differently.

That leaves traits_body, traits_modificators and traits_skill. At very least try to make icons for the first two, I expect the last one to be rather difficult.

[Xela]

I mean buttons inside GMs too, not just hovering somewhere. I'm actually going to use matrix inside village to search for quests, but when you already found a quest, I want buttons to advance through it.

What do you need exactly? It's prolly possible to do with an existing system, it's just not documented how.

But I'm not seeing the problem with the "dismod" method. Xela said it makes it them "universal gifts" meaning it affects all girls and so to avoid this he said most dismods will be set to 0 so that only traits affect it's disposition bonus, which makes sense. Still I'm not seeing the problem with universal gifts, they'll take more balancing, but I think the simplicity of the system is agreeable. Either way you'd have a simpler system with more complex balancing or a more complex system with simpler balancing.

I don't mind as long as it's well designed. Last I tested the system, almost any characters seemed to respond well to almost any gift, it wasn't how I imagined this feature to work. I'd prefer a wider variety of responses from them so there would be an intensive to learn something about the character first, before flooding them with gifts to gain disposition.

There are other ways we can balance it out, price vs current disposition for example... so design it as you see fit.

[DarkTl]

I'm not even sure how we check if the gift will be accepted or not, I don't have any such checks in my files... So I suppose you coded it 

For quests, when you accepted personal character's quest and fulfilled its current conditions, there should be a (custom?) button inside GMs that will allow you advance to the next stage of the quest. Another case is when you accepted personal character's quest to do something unique together with the character N times, there should be a button in GMs allowing to do it.

[Pseudononymous]

Yup, they are up to date. You can ignore traits_testing and traits_training, they are for testing and using in special cases. Also traits_class_mobs and traits_class jsons, they contain classes traits which will be handled differently.

That leaves traits_body, traits_modificators and traits_skill. At very least try to make icons for the first two, I expect the last one to be rather difficult.

On it boss.

[DarkTl]

Should I fix old traits in commented out sections too? Like def create_customer(self, name="") section in classes - unique buildings.rpy for example, favtraits are commented out.

[Pseudononymous]

Should I fix old traits in commented out sections too? Like def create_customer(self, name="") section in classes - unique buildings.rpy for example, favtraits are commented out.

I assume that question is meant for Xela, because I have no idea.

[Xela]

For quests, when you accepted personal character's quest and fulfilled its current conditions, there should be a (custom?) button inside GMs that will allow you advance to the next stage of the quest. Another case is when you accepted personal character's quest to do something unique together with the character N times, there should be a button in GMs allowing to do it.

We have that in place and you know how to work it... I know that you've edited all levels of Interaction menus!

It's just putting two and two together:

1) Player accepted a quest and fulfilled some of its conditions. At the end of such quest, you set some flag to a character.

2) You add a new button to interactions menus and condition it off that characters flag, it will obviously only work for that characters instance.

3) You have game jump to a label of your choosing from that menu to continue the quest.

===

Thewlis is logging in to FP but he never writes anything or answers to PMs. Even if I dive into his code, I doubt that I can come up with a better solution. Maybe I can help in a sense of generalizing the approach like writing a line of conditioning code that will check if a character has any True flag that starts with "event_to_interactions" and we agree on a MAX of one label for a character called for example:

Code: [Select]

label event_to_interaction:
and rest is handled from within that label. That way any modder can use it but since we have no modders atm that are capable of writing that level of quests, it may not (yet) be required.

Should I fix old traits in commented out sections too? Like def create_customer(self, name="") section in classes - unique buildings.rpy for example, favtraits are commented out.

No, that I will delete soon, you've already tagged all traits with special properties (basetrait, sexual, body, race, character and so on), new code will use that instead of strings.

I may ask you to help with vase patterns for characters but we are not there yet.

[DarkTl]

We have that in place and you know how to work it... I know that you've edited all levels of Interaction menus!

Yes, I can. It means however that every single personal quest for every single character will require a new modification of pyt - screens - interactions file. Sometimes more than just one. It hardly could be called a good solution for modding or even developing, the file will become messy very quickly.
What I mean is a system when there are hidden buttons at GM screen that become visible when a character has a quest flag, they lead to the labels you want, they have custom names that you can set somewhere without modding the main screen rpy file.

Basically, we check if there are quests that require buttons for the current character when we enter her GM, and if needed we make visible special buttons with custom names that you can set inside the quest logic.

[Xela]

Yes, I can. It means however that every single personal quest for every single character will require a new modification of pyt - screens - interactions file. Sometimes more than just one. It hardly could be called a good solution for modding or even developing, the file will become messy very quickly.
What I mean is a system when there are hidden buttons at GM screen that become visible when a character has a quest flag, they lead to the labels you want, they have custom names that you can set somewhere without modding the main screen rpy file.

Basically, we check if there are quests that require buttons for the current character when we enter her GM, and if needed we make visible special buttons with custom names that you can set inside the quest logic.

Thewlis is logging in to FP but he never writes anything or answers to PMs. Even if I dive into his code, I doubt that I can come up with a better solution. Maybe I can help in a sense of generalizing the approach like writing a line of conditioning code that will check if a character has any True flag that starts with "event_to_interactions" and we agree on a MAX of one label for a character called for example:

Code: [Select]

label event_to_interaction:
and rest is handled from within that label. That way any modder can use it but since we have no modders atm that are capable of writing that level of quests, it may not (yet) be required.

This...?

[DarkTl]

Well, you proposition is a bit vague. How I imagine it exactly:
- Either new submenu for quest buttons (called events for example) that is hidden when there are no quest options available, or simply buttons that have a different color. This way players will immediately notice quest options in GMs.
- If character has a True flag starting with event_to_interactions, a quest button appears inside GMs that will lead to specific label, for example label event_to_interactions_lbl_"name of that true flag without "event_to_interactions" part". That will allow us to use multiple buttons.
- The difficult part here is to use custom names for those quest buttons. I'm not even sure if it's possible or where to set those names in the code to make it work.

[Xela]

I have a decent idea, for both, button name and conditioning that will work like you describe. Actually coded exactly like you described

Gonna try adding it tonight.

[Gismo]

I have a question.
There are too many screens with items (hero_profile - Eqipment (with doll) ... girl_equip (with doll) ... items_transfer (from hero to one girl) ... items_transfer (from one girl to another) and they are all in different places.
Much confusion, the player must remember that dress up items on the hero can only be in his profile > same to girl but in girl profile > you can transfer items from hero to girl with only from her profile screen (top strip button) > and transfer items from girl to girl only at brothel_management screen.

How about we make one screen instead of so many?
- the buttons will be in hero_profile and girl_profile
- all the right buttons to transfer items will also be here
- you can equip as a hero and a girl from this screen (with different dolls)

I can try to make it.

[Xela]

So you suggest:

1) Use current girls equip screen to equip anyone.
2) Use transfer items screen to transfer to anyone who is available by default (from any screen) or to between sensible range of characters when calling it, for example from a building.

===
It makes some sense but unique eq screen for MC is also kinda cool. Items transfer is handled logically on per location basis (between chars in a building for example, those are not "all" girls as you stated).

I don't mind either way, lets see what others have to say...

[DarkTl]

Yes, we need it. I played many games, and we have the most confusing items gui I ever saw (not the most inconvenient though). I know how to find all options only because I asked on the forum 

[Xela]

Confusing how? Due to multiple equipment screens or buttons that lead to them or buttons that lead to items transfer?