General Discussion

[Xela]

Fun... reading that code... it's impossible to equip any item on a slave, nothing will happen if you try

[DarkTl]

Our approach here is prolly f*cked. Rather than managing all of that logic, we could have simply blocked the corresponding buttons. Of well... since it's working already...

By all means, block all buttons and add to the tooltip why they were blocked to not confuse players.

Throw it in the dev menu (I've updated it, put it under logic).

Oh boy, it's another win10 + scaling factor thing 
Guess I'll disable scaling, and in the game requirements should be mentioned how it's not supported for win10.

[Xela]

how it's not supported for win10.

How it doesn't support win10 scaling... or do you have other issues? By the time we release, this will prolly get fixed.

[DarkTl]

Yeap. On 7 and 8 it works with any scaling, so scaling is not a problem by itself.

[DarkTl]

Fun... reading that code... it's impossible to equip any item on a slave, nothing will happen if you try

My bad. I didn't paid attention how it will work for permitted items after changing it to deny armor and shields too.

[Xela]

My bad. I didn't paid attention how it will work for permitted items after changing it to deny armor and shields too.

I thought it was my code. It wasn't supposed to be there in the first place, let me settle all of that cr@p.

[Xela]

Ok... so the cr@p is prolly all sorted:

Code: [Select]

All cases when a character refuses to give away an item should lead to one set of lines. That includes attempts to discard items.
Although, since we have at least two different screens to transfer items, it might not be possible to make them use the same set.

All cases when a character refuses to equip an item should also lead to one set of lines. Different from the previous one.
It all came down to one more function (maybe two, I am kinda hoping we can stuff all into one)... and it should be possible to use it everywhere.

Code was very complicated, while it prolly should not have been. I don't think it was working properly either, it may be now but that is not complete yet. So:

When we equip or unequip and item in that screen we always can equip and unequip from/to player/chars inventories. There was a lot of really complex if/else forks at play there but I think we can safely remove all of that and do this:

Code: [Select]

                    if item_direction == 'equip':
                        # Common to any eqtarget:
                        if not can_equip(focusitem, eqtarget, silent=False):
                            focusitem = None
                            selectedslot = None
                            unequip_slot = None
                            item_direction = None
                            dummy = None
                            jump("char_equip_loop")
                           
                        # See if we can access the equipment first:
                        if equipment_access(eqtarget, focusitem):
                            # If we're not equipping from own inventory, check if we can transfer:
                            if eqtarget != inv_source:
                                if not transfer_items(inv_source, eqtarget, focusitem):
                                    # And terminate if we can not...
                                    jump("char_equip_loop")
                                   
                            # If we got here, we just equip the item :D
                            equip_item(focusitem, eqtarget, area_effect=True)
                           
                    elif item_direction == 'unequip':
                        # Check if we are allowed to access inventory and act:
                        if equipment_access(eqtarget):
                            eqtarget.unequip(focusitem, unequip_slot)
                           
                            # We should try to transfer items in case of:
                            # We don't really care if that isn't possible...
                            if inv_source != eqtarget:
                                transfer_items(eqtarget, inv_source, focusitem, silent=False)
Most important new thing here is equipment_access function. It will determine if char would be willing to give MC access to their inventories. Because if not... it doesn't really matter what conditioning follows, that check needs to be passed first.

So... I stuffed the usual rules we had here into that func but it's not enough. For "equipping" items, we need one extra parameter: item. Even if the character doesn't like you well enough, if it's a good item like a health potion for example, there should be no reason to refuse.

@Dark:
You know items logic as well as I (prolly better cause you made most of the items). We need to figure out when a char might want to allow access to inventory even if MC is not liked... You can add conditions to the function or write those here and I'll add them. item argument will not be used when unequipping an item and when discarding one. Transferring items has a function of it's own with separate responses.

[Xela]

And obviously, when you write the lines, make them appropriate, like I'll manage my own things! and not "Get away from my stuff!", because you may be trying to equip your own item to the char as well.

[DarkTl]

Uh, so far I added lines for the big transfer screen in buildings menu, which only handles transferring items.
Lines from char.say(choice(["I can manage my own things!", "Get away from my stuff!", "Don't want to..."])) are yours 

Then again, you simply can disable transfer buttons even there, it's cleaner then showing refusing lines every time. And do the same for equipping button instead of that line above. The problem here is to make it clear why buttons are unavailable. If renpy can manage local tooltops like in windows, when a small window with explanation appears next to cursor only when needed, it might be the best way.

So... I stuffed the usual rules we had here into that func but it's not enough. For "equipping" items, we need one extra parameter: item. Even if the character doesn't like you well enough, if it's a good item like a health potion for example, there should be no reason to refuse.

type=="restore" items can be always available then. Although, with disposition < -700 and status<>"slave" anything should be unavailable, I think.
For other items we have goodtraits field. Character has no reason to refuse if goodtrats match her traits, unless disposition < -700 again.

That's it, if we involve too many exceptions, the very idea of locked characters inventories will become obsolete.

You know items logic as well as I (prolly better cause you made most of the items). We need to figure out when a char might want to allow access to inventory even if MC is not liked...

What do you mean by access here? Full access, like for slaves?

[Xela]

Uh, so far I added lines for the big transfer screen in buildings menu, which only handles transferring items.
Lines from char.say(choice(["I can manage my own things!", "Get away from my stuff!", "Don't want to..."])) are yours 

I know, I think that this line that doesn't fit was common to all of those responses. Just pointed out that this isn't a good "generic" option.

Then again, you simply can disable transfer buttons even there, it's cleaner then showing refusing lines every time. And do the same for equipping button instead of that line above. The problem here is to make it clear why buttons are unavailable. If renpy can manage local tooltops like in windows, when a small window with explanation appears next to cursor only when needed, it might be the best way.
type=="restore" items can be always available then. Although, with disposition < -700 and status<>"slave" anything should be unavailable, I think.
For other items we have goodtraits field. Character has no reason to refuse if goodtrats match her traits, unless disposition < -700 again.

I have, partly. But disabling buttons is way less personal than char responding appropriately. I am not sure if this "emmersion" will come out infuriating to the player at the end. I kinda like it myself, but I am not sure that everyone else will.

Also, we should add items with really, really high eqchance (or what ever that was called) to this. Maybe also add different responses? Like when you give an item that is a match on traits: "Thanks, you know me so well!". And on high eq chance: "This will be useful!" and etc. Not sure about restore items, there are some bad items that restore, are they now? Maybe also when paired with a eq check.

That's it, if we involve too many exceptions, the very idea of locked characters inventories will become obsolete.
What do you mean by access here? Full access, like for slaves?

Yeap, too much would be weird, still, might be a good idea to add the above. I am not sure about this one...

I mean when this function returns True.

[DarkTl]

You can add items with eqchance >= 70 too then. It's always very good, rare and expensive items. Of course there always should be checks for bad traits too.

Badness determines how willingly an item will be bought by character. We do it 0 for healing potions, and all characters have dozens of them, it's a bad thing for gameplay. While if the character needs healing a lot, she should be able to buy one without even looking at badness. In fact all "restore" items are safe, that's what items types are for.

If you want, you can check if char.health < max char health before allowing to consume health potions, and so on for mp and vitality.

Also, we should add items with really, really high eqchance (or what ever that was called) to this. Maybe also add different responses? Like when you give an item that is a match on traits: "Thanks, you know me so well!". And on high eq chance: "This will be useful!" and etc.

I think lines from gifts will suit such cases perfectly.

[Xela]

Ok, I think that we got conditioning straight. Auto-Buy we're not doing at the moment, if I remember that method, it is already very complicated... we'll review it in either case but I want to clear this issue first.

[DarkTl]

And on high eq chance: "This will be useful!" and etc.

Yeah. Like, you equip a maid set on a character with maid class, and she makes positive comments about every single item from the set 
No thanks.
 

[Xela]

Yeah. Like, you equip a maid set on a character with maid class, and she makes positive comments about every single item from the set 
No thanks.

Fair point... no comments

[Xela]

We should prolly have "goodoccs" and "badoccs" fields as well. Just for strings like "Warrior"/"Manager" and etc. It's clumsy at best and impossible at worst to tell which was meant to be used when, for example:

"Warrior" is provided. It can mean a general string to whom anything that increases defense is automatically useful but Mage/Warrior would both have a Warrior occ string and it's no clear if a Warrior wants a staff...

What do you think?