General Discussion

[DarkTl]

Done with AA, another push. I used our new rts function for interest label, works flawlessly. I will add more lines later where they are needed.

Now, what can I say about girlsmeets:
- All girlsmeets options should be available from interactions menu, at least temporarily and/or in dev mode. Because it's kinda hard to test some options when you have to look for specific girl at first.
- Compliments and insults should be processed differently, but have same replies. Ie dumb/boring/ugly success should depend on girl's stats, for example int/character/charisma, but return the same type of replies. I guess I should use jump option for replies, but I need opinions about stats.
For example, let's take stupid insult. Should it be more effective on a smart girl (because she is proud of her intelligence) or on a silly girl (because she knows that it's actually true)?
- Don't mind date labels. It's just some lines that could be useful in the future.
- We already could use friend and lover statuses, even if they won't do anything for now. I added lines for both propositions and greetings for lover status.

[CherryWood]

Added tavern location. But it's empty and meaningless now, because I don't have any quest ready yet and I couldn't figure anything useful for MC to do there that's not just a total waste of time and money with nothing gained     


/I'll try to work on my missing item descriptions now.

[Xela]

Done with AA, another push. I used our new rts function for interest label, works flawlessly. I will add more lines later where they are needed.

Now, what can I say about girlsmeets:
- All girlsmeets options should be available from interactions menu, at least temporarily and/or in dev mode. Because it's kinda hard to test some options when you have to look for specific girl at first.
- Compliments and insults should be processed differently, but have same replies. Ie dumb/boring/ugly success should depend on girl's stats, for example int/character/charisma, but return the same type of replies. I guess I should use jump option for replies, but I need opinions about stats.
For example, let's take stupid insult. Should it be more effective on a smart girl (because she is proud of her intelligence) or on a silly girl (because she knows that it's actually true)?
- Don't mind date labels. It's just some lines that could be useful in the future.
- We already could use friend and lover statuses, even if they won't do anything for now. I added lines for both propositions and greetings for lover status.

How should "All options availible" look like? You can add them as menu choices just by looking at code yourself, it's basically just jumps to girlsmeets labels. We could create "body" labels with texts and call them from iteractions labels and girlsmeets labels as required, maybe even with different intos. If you can describe how you want to do it, Thewlis or I can fix something up (that code should be very easy to understand).

I don't know if we should add complex behaviour/responses like different behavior on isults for later (after next release)?

As for friend/lover status, you need graphical representation in the profile? If not, you can just set flags and check agaist them:

$ chr.set_flag("lover")

if chr.flag("lover"):
    # responce
============================

Added tavern location. But it's empty and meaningless now, because I don't have any quest ready yet and I couldn't figure anything useful for MC to do there that's not just a total waste of time and money with nothing gained     

I am trying to pull that right now Some events and maybe even a purpose and tavern will be lovely!

[DarkTl]

I don't know if we should add complex behaviour/responses like different behavior on isults for later (after next release)?

It's not really complex. I'll just check the stat and throw disposition penalty/bonus in case of masochist depending on that using a simple formula. However, I can't decide how should it work, dammit 

How should "All options availible" look like?

I thought about a "meet" button that calls usual girlsmeets menu on spot even for hired girls.

$ chr.set_flag("lover")

if chr.flag("lover"):
    # responce

Ok, that settles it.

[Xela]

I thought about a "meet" button that calls usual girlsmeets menu on spot even for hired girls.

Ok, I am too tired to look into that atm. It should be possible without too much fuss (I hope).

[Xela]

I've got a working mock up for custom location actions if we want them.

Currently in the label for the locations, before we show the location-specific screen we put:

Code: [Select]

# If we have no actions
    python:
        if pytfall.world_actions.location("city_beach"):
            pytfall.world_actions.meet_girls()
            pytfall.world_actions.look_around()
            pytfall.world_actions.add("Sunbathe", "sunbathe")
            pytfall.world_actions.finish()

Which creates the actions for the location. The location() function either returns False if the location is already set up, or True and creates a set list of actions for it.

These functions create controls there were considered general enough to have a ease-of-use function:
meet_girls() creates the normal Meet Girls button.
look_around() creates the normal Look Around button.
slave_market() creates the Go Shopping slave market button.
work(flag=None) creates the Work button.

add() adds a new action button, with the arguments:

• button = The name of the button.
• action = The string to use as an event trigger, or a screen action.
• label = The label to go to if no event can be run ("_events_not_found" for Look Around for instance).
• cost = The cost of triggering the event. 1 by default.
• flag = The global flag to check for screen actions.
• null_button = The label to use if the button should be null ("No Slaves Available" for instance).
• null_condition = The condition to check to see if the button should be null (can be a string, a function or a variable).

In the actual screen we put:

Code: [Select]

use location_actions(pytfall.world_actions("location name")
Which simply adds a vbox that loops through the available actions and adds a textbutton for them. Actions are only added if they have a default label or at least 1 action in the WorldEventsManager.label_cache that uses its action as a trigger if they are an event trigger, else checks its flag.

The WorldEventsManager.run_events() function has been modified to accept "default=None" and "cost=0" arguments as well, so the run_events("auto") calls don't need to be updated.

This isn't pushed?

I am not 100% sure this approach beats buttons/screens but this seems exactly what CW asked for and this should serve all our needs.

[Thewlis]

Yeah, I can push it now.

Currently the code for the action classes are in library/events/classes - events.rpy. The new action code is only set up for the main beach (the one accessable from the main map), the slave market and the outside arena. They test all the different actions/properties the button are built with.

See if you like it and if its worth following I can update all the other locations.

[Gismo]

Push small update:

- New mainscreen tooltip frame
- A new framework for dialogue
- New button for choise menu
- Returned back old gallary screen 






Need to do one more click after preview to see screenshot at full quality.

[Xela]

Great job!

Some tinkering will be required like:

- making sure choice button size doesn't change when hovered over.
- making sure text starts closer to the left window frame when there is no portrait.

[Xela]

Yeah, I can push it now.

Currently the code for the action classes are in library/events/classes - events.rpy. The new action code is only set up for the main beach (the one accessable from the main map), the slave market and the outside arena. They test all the different actions/properties the button are built with.

See if you like it and if its worth following I can update all the other locations.

I can take a look but it sounded like a much better system then we have now. I see no reason not to keep it.

[Xela]

Minor SF Update:
- Wrote "new style" styles to fit Gismos say window code
*Only in dev mode:
- Added girlsmeets activation from interactions as Dark requested. (minor glitches after leaving girlsmeets present, just reenter interaction to fix)

I can take a look but it sounded like a much better system then we have now. I see no reason not to keep it.

That was a "Definite Yes!" btw

Edit (Thewlis from the future):



LoL?

[Thewlis]

All the locations now use the new actions system.

Some slight changes:

Code: [Select]

pytfall.world_actions.location("city_beach")
pytfall.world_actions.add(0, "Stay", Jump("pyt_wip_screen"), flag=("tavern_entry_brawl", "!=", day+hero.AP))
pytfall.world_actions.meet_girls()
pytfall.world_actions.look_around()
pytfall.world_actions.finish()


• location() no longer returns a bool. It just accesses/creates the actions list for the location.
• add() requires you to pass a key as the first argument. The keys are used for ordering the actions and for replacing/removing the current actions.
  work() uses key -2.
  slave_market() uses key -1.
  meet_girls() uses key 100.
  look_around() uses key 101.
• The parameters "flag" and "null_condition" can now accept a 3 length tuple that contains a condition formatted as: ("flag", "condition", value).
  "condition" can be all the standard python binary operations.

[Xela]

All the locations now use the new actions system.

Some slight changes:

Code: [Select]

pytfall.world_actions.location("city_beach")
pytfall.world_actions.add(0, "Stay", Jump("pyt_wip_screen"), flag=("tavern_entry_brawl", "!=", day+hero.AP))
pytfall.world_actions.meet_girls()
pytfall.world_actions.look_around()
pytfall.world_actions.finish()


• location() no longer returns a bool. It just accesses/creates the actions list for the location.
• add() requires you to pass a key as the first argument. The keys are used for ordering the actions and for replacing/removing the current actions.
  work() uses key -2.
  slave_market() uses key -1.
  meet_girls() uses key 100.
  look_around() uses key 101.
• The parameters "flag" and "null_condition" can now accept a 3 length tuple that contains a condition formatted as: ("flag", "condition", value).
  "condition" can be all the standard python binary operations.

Awesome! Your new setup seems to be woking flawlessly. I just pushed a small fix for the annoying fading out of main screen background as well.

[DarkTl]

Edit (Thewlis from the future):

He knows first-hand how awesome the game will be in the future, that's why he joined us via temporal proxy.

I noticed some problems with buttons. That's probably has nothing to do with new buttons icons, but I still decided to test them, and in some cases they don't work as expected. Usually when one screen is opened, and you try to open another one.

[Xela]

I noticed some problems with buttons. That's probably has nothing to do with new buttons icons, but I still decided to test them, and in some cases they don't work as expected. Usually when one screen is opened, and you try to open another one.

Prolly a bug in Ren'Py. Where did you encounter this error?