General Discussion

[DarkTl]

It may also require a function so the area doesn't "jump" around... which reminds me, do we want this area to jump around every time screen is activated or should it's position be randomized just once?

Ideally, it should be under control. When we need to randomize random matrix anew, we do so. When we don't, we don't.

If it's too much trouble, it should be randomized every time you enter it.

[Xela]

This limitation will bite us in the future if we'll have multiple bgs for the very same location depending on the time (morning/day/evening/night).

It's totally wrong to call this a "limitation" in any sense of form. As I've said, you can specify background when you call the GM, it's a major convenience... not a limitation. Not mentioning that if in some ridiculously improbable scenario where we add times of day, we will prolly still use generalizations like this by adding appendixes to image names and using color masks if there are none (once again, with a possibility to specify exceptions).

Ohhkey, as long as it works just like a normal matrix but with one or more randomly placed areas, it's fine by me.
I don't need it for a normal matrix.

Oki, then it's prolly done, just untested.

Well... I want to use it to randomly hide items and events. It means that after you found an item or an event, the area should no longer be there at least until the next day.

Ideally, it should be under control. When we need to randomize random matrix anew, we do so. When we don't, we don't.

You prolly want to condition this yourself... I am going to leave as much freedom as possible and recode the screen to take more args just so positions could be randomized outside of it.

[DarkTl]

It's totally wrong to call this a "limitation" in any sense of form. As I've said, you can specify background when you call the GM, it's a major convenience...

I feel like storing the current background in a variable, like gm.label_cache does for labels, and use it for GMs is a better solution.

[Xela]

I feel like storing the current background in a variable, like gm.label_cache does for labels, and use it for GMs is a better solution.

That's what I am saying... it IS!

Code: [Select]

self.bg_cache
is the field. When you start gm:

Code: [Select]

def start(self, mode, girl, img=None, exit=None, bg=None):
You can specify background. If you do NOT:

Code: [Select]

            elif bg is not None:
                self.bg_cache = "bg " + bg
which is an error left by Thewlis I think, it should just be:

Code: [Select]

self.bg_cache = bg
But I don't think we ever used it so it's prolly not debugged or debugged to work with the error.

[Xela]

Oki, pushed another update, it should ensure that shield is not shown for "fly_away" damage type, effects will still be applied! Gonna hack BabeRunner for a while.

[DarkTl]

I've mentioned this before a couple of times, game expects image to be named after the label or this default behavior to be overridden when calling interactions. Girlsmeets are f*cked, so that was the error... renaming the image is prolly simpler.

Right, so why is this expected? The game basically uses gm.label_cache as self.bg_cache instead of having independent gm.bg_cache which is not tied to labels. Is it impossible to do?

[Xela]

Right, so why is this expected? The game basically uses gm.label_cache as self.bg_cache instead of having independent gm.bg_cache which is not tied to labels. Is it impossible to do?

... lol?

I don't know how many more ways are left there to say it

They are independent if you want them to be:

Code: [Select]

label swimming_pool:
    ...
    while 1:
        $ result = ui.interact()
       
        if result[0] == 'jump':
            $ gm.start_gm(result[1], bg="pool_inside_background_image")
and you have it your way. But there is no reason to do this... because the other way is automatic and is used almost everywhere else.

[DarkTl]

I mean, when we write scene bg swimming_pool, can't it be automatically saved in a variable and used by GMs or any other system?

[Xela]

I mean, when we write scene bg swimming_pool, can't it be automatically saved in a variable and used by GMs or any other system?

Sure... but why? You can rebind the tag:

Code: [Select]

image bg swimming_pool = ...webm background with waves?
Backgrounds are bound automatically at init -999 but you can overwrite them at later inits. The example default to init 0. GM will pick it up using the usual mech described above (bg + label_name).

[DarkTl]

I am worried about spell/skill imbalances... And Buff is now "fixed", feels like there should be a "caster" bonus in it. We'll have to set some time aside to balance everything in terms of cost and power and menupos before release.

We'll also prolly need more flags with skills, those will be needed for writing algorithms when building NPC warriors of all sorts. Same prolly for items but we have a lot of flags there so it might be ok.

I suppose the buffs defence_multiplie could be min(caster.magic*0.01, 0. 8) .

If you try spells/skills vs characters of high levels, for example vs Nami after BE testing mode upgraded her, they won't look overpowered, even the strongest ones.

Skills are tied to weapons, we could just equip a weapon when we build warriors.

[DarkTl]

I wonder why in the dev mode MC doesn't have specific items types, like those with "slot": "loot". Even though it's done via

            for i in items.values():
                h.inventory.append(i, 5)
                hero.inventory.append(i, 5)

They don't count as items or something? I kinda need them for testing.

[Xela]

I wonder why in the dev mode MC doesn't have specific items types, like those with "slot": "loot". Even though it's done via They don't count as items or something? I kinda need them for testing.

Really? I'd expect them to be there... maybe we're filtering them out in the inventory screen itself?

[DarkTl]

Oh boy...

            if last_label in ("items_transfer"):
                self.FILTERS = self.GEQ_FILTERS
            else:
                self.FILTERS = self.ALL_FILTERS + ["resources"] # TODO: Fix this to a more sound design.

This is a very bad design with little to no control over items filters. We need a high degree of control over inventory categories because we have more categories than space in gui.

[Xela]

Oh boy...This is a very bad design with little to no control over items filters. We need a high degree of control over inventory categories because we have more categories than space in gui.

Suggestions? I think that we talked about not showing filters for which char doesn't have items for at all. And combining some items types into single filters... otherwise we'd have to mess with GUI. Better would be to disable filter buttons by greying them out but that wouldn't save us any GUI space.

I've been messing with BR a lot, gonna wrap up some stuff there and put some time into PyTFall tonight/tomorrow.

[DarkTl]

I think that we talked about not showing filters for which char doesn't have items for at all.

It's for shops only, where unnecessary, unused filters look messy. If cafe doesn't buy or sell anything but consumables, then showing there filters for anything but consumables is 100% pointless and also possibly confusing for some players.

And combining some items types into single filters...

Yup, we need filters to show more than one slot when needed. Even your resources items should be in some specific category, probably together with loot items, instead of being visible in ALL filter only.