General Discussion

[DarkTl]

I mean, either we remove MC teammates from his team, or forbid to include them into teams unless you send MC himself to exploration (in which case the game uses them as his team). They physically leave the city, there is no way they can explore some distant area and follow MC at the same time.

Edit: yeah, it sounds kinda vague now when we have two types of teams, MC's team and SE teams 
If we allow to send to SE characters from MC_team, we should remove them from MC_team when they join SE_team. Either that, or we forbid characters from MC_team to join any SE_teams, unless player forms a SE_team by dragging MC to team frame, in which case characters from MC_team also became a part of his own SE_team.

Another option is to make MC's own SE_team permanent and undeletable,  and synchronize it with MC_team. Or, rather, make MC_team and his own SE_team the same thing. When player adds a character to MC_team, he also adds that character to MC's SE_team, and vice versa.

[Xela]

I can prolly figure this out, we don't have much in terms of actual exploration logic.

[DarkTl]

BE probably should use random music if no music is specified. It looks very weird when they fight in silence.

I need to initiate a battle inside interaction. Well, not inside, but after some action I need to exit interaction screen, run BE, then depending on result call interactions labels for the character to say something, basically return to interaction screen.

[Xela]

BE probably should use random music if no music is specified. It looks very weird when they fight in silence.

I need to initiate a battle inside interaction. Well, not inside, but after some action I need to exit interaction screen, run BE, then depending on result call interactions labels for the character to say something, basically return to interaction screen.

Provide a music file if it looks weird.

You can just run BE as a single python statement never leaving interaction label so there shouldn't be any issues.

[DarkTl]

I kinda thought default = random, not none... Why providing music files manually when we have plenty to choose from with rng? Why the same scene (like arena battle) should always have the same music with zero variety?

You can just run BE as a single python statement never leaving interaction label so there shouldn't be any issues.

No, there are plenty of issues, such as all elements of interactions gui remaining on the screen.

[Xela]

No, there are plenty of issues, such as all elements of interactions gui remaining on the screen.

Hide them

Code: [Select]

hide screen name before launching BE.

[DarkTl]

I need to know somehow where gm was started to provide a suitable background for BE.

[Xela]

I need to know somehow where gm was started to provide a suitable background for BE.

We store three variables when an Interaction (GirlsMeets, poorly named, I'll adjust on refactoring) starts:

Code: [Select]

            self.label_cache = ""
            self.bg_cache = ""
            self.jump_cache = ""
 I am not sure but jump_cache might be something interim. label cache is prolly safer.

[Xela]

Do you want to show all warriors in all buildings, or player has to transfer characters to the guild before they appear in the list? I'm not really sure what is the best way, showing everyone could be very messy, even with filters per building...

Anyway, I believe we need sorting by level and by character name at the teams screen. I don't see the game using buttons-switches so far, when one button can have many icons and/or text depending on the current mode, and clicking on it changes the mode. Such buttons are probably the best bet for filters like name/level.

Also, MC teammates cannot be a part of SE, unless MC is a part of SE too. We probably could set them as his team automatically once you drag MC to a team frame.

Tonight I want to try making filters generic and reusable through one class (rewriting/renaming the GuiGirlsList class basically).

[DarkTl]

Yeah, gm.label_cache works fine. Although you mentioned that characters should (or will) have current location property, I imagine it should be the most reliable way for such checks.

[Xela]

Although you mentioned that characters should (or will) have current location property, I imagine it should be the most reliable way for such checks.

Yeap but it might not get this precise. It's that "eternal" argument of "Moar Logic" vs "Unmanageable Cluster Fuck of code". I'd argue that for the game, location for a free character that is available to interact in the city should be simpler than the exact place where that char can be found...

[DarkTl]

We could use a shortcut button in BE to lose the battle to test outcomes of losing. There are various ways to to get around it, such as starting as zero mc or changing the code, but they are less convenient than such a button.

[Xela]

We could use a shortcut button in BE to lose the battle to test outcomes of losing. There are various ways to to get around it, such as starting as zero mc or changing the code, but they are less convenient than such a button.

Come on... don't run the BE at all and preset data to whatever the conditions you wish to test, what can possibly be any different? How can it possibly be easier for me to change GUI and for you to wait for BE to start every time than for you to just not run BE and test various outcomes through menu or just code that runs through?

It's like we're back to that discussion about not being able to create quests before SE kicks in. You can easily simulate outcomes of whatever the hell was supposed to have happened in BE or SE or anywhere else without ever having to run them cause all they can offer is to return a list of corpses/alive team mates/set a flag/add an item and etc. and even all of those slightly more complex conditions, in the end, boil down to a simple True/False...

[DarkTl]

Come on... don't run the BE at all and preset data to whatever the conditions you wish to test, what can possibly be any different?

Usually the lack of music, background and other needed pictures, which can only be noticed after closing real BE, since you have to return everything manually after using BE 

Btw how to implement results of BE to characters? Like, remaining health and mp.

You can easily simulate outcomes of whatever the hell was supposed to have happened in BE or SE or anywhere else without ever having to run them cause all they can offer is to return a list of corpses/alive team mates/set a flag/add an item and etc.

Not quite. For example, let's say I 'm planning to run a scene when the team finds something in SE (but hasn't returned yet). But turns out SE can't support such stuff, goodbye scene. Well, I dunno if it will be able to support it, it's just an example.

Another example, let's say I'm planning to make an event where MC has no choice but to run from BE because the enemy is too powerful. But even now BE doesn't support running away, goodbye event.

[Xela]

Usually the lack of music, background and other needed pictures, which can only be noticed after closing real BE, since you have to return everything manually after using BE 

Button to terminate the engine quickly does make sense, I did add that for my own testing, although it will send you to main screen. This has nothing to do with loosing or winning, I'll try to make sure that it can function anywhere somehow and push.

Btw how to implement results of BE to characters? Like, remaining health and mp.

You have access to teams in the order you've added them to be instance (be.teams field, it's a list) or to team objects you've created.

Not quite. For example, let's say I 'm planning to run a scene when the team finds something in SE (but hasn't returned yet). But turns out SE can't support such stuff, goodbye scene. Well, I dunno if it will be able to support it, it's just an example.

You can just ask about complicated cases like these and than just go on with your quest development, it doesn't prevent your from doing anything.

Another example, let's say I'm planning to make an event where MC has no choice but to run from BE because the enemy is too powerful. But even now BE doesn't support running away, goodbye event.

That is some intense BS right there

One: It's obvious that we can create this action. So it's not that BE doesn't support it, it's that running away isn't coded in yet.
Two: It's not really all that different from getting your party wasted in a none "battle to the death" scenario which should be our default.
Three: Yet another thing that you that you can plainly ask about.

===>>
I'll look into adding a run away sequence as well. For the whole party at first, maybe per character later on, which will prolly require creating a lot of new variables...