<-- Archived -->

[DarkTl]

My understanding is your system solve disposition problem for consumables only. Am I wrong?

If we talk about some dress with mod disposition = 10, then girl will have these +10 only when it equipped (and loses when unequipped), not when she receives it as a gift.

[Xela]

My understanding is your system solve disposition problem for consumables only. Am I wrong?

If we talk about some dress with mod disposition = 10, then girl will have these +10 only when it equipped (and loses when unequipped), not when she receives it as a gift.

True, you're prolly right... I can't think about it right now, trying to figure out this trait/item bs.

[Xela]

True, you're prolly right... I can't think about it right now, trying to figure out this trait/item bs.

Phew... I think I figured it out. Was a lot easier than it seemed at first

Problem was with items awarding/removing traits... What I did in the code was simply to apply/remove traits as items are equipped in symmetry (that was obviously stupid). WM is also kinda bugged when it comes to items/traits so that was no help. In the end I think we got a decent system right now (still in need of testing), there is such a thing as 'truetrait', girl either starts with that trait, earns it through hard work or gets it from non temporary consumables or misc items. Second layer of a  trait is kinda soft layer that comes from equipped items and consumables with temporary effects.

[Xela]

My understanding is your system solve disposition problem for consumables only. Am I wrong?

If we talk about some dress with mod disposition = 10, then girl will have these +10 only when it equipped (and loses when unequipped), not when she receives it as a gift.

Yeap, now that I had time to think about it, you're right. So we can either award whatever normal <mod disposition/> does as player gives/buys girl an item (divide or multiply by any value that is possible as well) or use dismod field as you suggest. I think either way will work just fine so you can choose.

[DarkTl]

Second layer of a  trait is kinda soft layer that comes from equipped items and consumables with temporary effects.

Does it mean that now any type of item can safely give a temporary trait, not just consumables and miscs?

I think either way will work just fine so you can choose.

Well, if you ask me, I would prefer dismod in some kind of formula. Gift-type consumables are universal gifts (flowers, alcohol, sweets, etc), almost anyone would love them. Therefore a static number suits it well.

However, service girls, not to mention whores, have little need for powerful, big weapons not matter how rare they are. Warriors prolly do not refuse an average dress as a gift, but they don't have many opportunities to wear it anyway, so they still would prefer some armor.

We can't take into account everything (or better to say, we could, but after a couple years of coding  ), but still this system will be more plausible than WM-like.

In other words, I propose to calculate disposition bonus depending on dismod field, girl's occupation and good/bad trait list. We could also do it without new field, taking as a basis item's rarity (chance field) and cost.

If you dislike the idea, or it will take too many time, simple dismod will be fine.

[Xela]

Does it mean that now any type of item can safely give a temporary trait, not just consumables and miscs?

It's best to test stuff like that just in case.

Should work like this:

If you add the temp trait through a consumable/misc, it'll be perfectly safe.

If you add the temp trait through an equipable type of item, it will activate but it will disappear if you unequip the item... (this I can fix by the way and have the temp trait stick even if item is removed, but I cannot really see what's best here).

If you have the trait going already, equipping the item will not do jack, neither will taking the item off remove the trait.

I cannot see how this is of an use btw...

Well, if you ask me, I would prefer dismod in some kind of formula. Gift-type consumables are universal gifts (flowers, alcohol, sweets, etc), almost anyone would love them. Therefore a static number suits it well.

However, service girls, not to mention whores, have little need for powerful, big weapons not matter how rare they are. Warriors prolly do not refuse an average dress as a gift, but they don't have many opportunities to wear it anyway, so they still would prefer some armor.

We can't take into account everything (or better to say, we could, but after a couple years of coding  ), but still this system will be more plausible than WM-like.

In other words, I propose to calculate disposition bonus depending on dismod field, girl's occupation and good/bad trait list. We could also do it without new field, taking as a basis item's rarity (chance field) and cost.

If you dislike the idea, or it will take too many time, simple dismod will be fine.

Well, we can start with dismod field (to be added to xml in the same way as hidden and will default to false if not specified). Formula we can figure out later, this will work better if we decide on types for items, like Armor/Dress so the game knows which is which... I suggest we start simple and build on it like I always do

[DarkTl]

I cannot see how this is of an use btw...

I guess I put it badly. As you mentioned before,

Only consumables (without temp effect) and misc items should award traits because if girl already has a trait that is awarded to her by a wearable item (ring or cape for example), trait will disappear as item is taken off

However, WM has, for example, a dress which gives Elegant trait when equipped (so it's actually a temp trait, because it will disappear if you unequip it). Is it safe now to port it in Pytfall?

[Xela]

However, WM has, for example, a dress which gives Elegant trait when equipped (so it's actually a temp trait, because it will disappear if you unequip it). Is it safe now to port it in Pytfall?

// I thought you mean temporary traits (Like Caught a Cold) not normal traits being awarded/removed while girls has item equipped

Yeah it should be 100% safe now, that's exactly what I've been trying to get to work perfectly.

What happened today was:

I equipped Hinata (loaded without traits) with your Maid Uniform item. Equipping worked fine, she got an Elegant trait (Aggressive trait wasn't removed cause she had none). However when I took the item off, effects were reversed, Elegant was removed and Aggressive added (that would cause a complete chaos in the long run).

So I went to WM for a consultation but system there while working better, still had fundamental flaws like a girl who has Elegant trait already and equips TWO or more items that should 'temporary' remove Elegant trait, looses her trait. More flows when you have a number of items that take away or add the same trait equipped at the same time (there is a chance that you'll get stuck with the trait).

In the end I came up with a three layered approach that should fix all these issues:

- Girls being awarded a trait for hard work/training while same trait is already being enforced by an item.

- Girl having a trait, putting on an item that adds the same trait, than loosing the original trait but still keeping the trait until item is unequipped.

- Girl having a trait, then equipping two or more items that should 'temporarily' remove or add the trait, without loosing the original trait in the process (trait should come back when all items are unequipped if items removed it).

- Trait being active if girl originally had a trait, then put on an item that removed it and another item that added the same trait.

It all needs to be tested by it should now all sort itself out...

[DarkTl]

I see. Well, these solutions (for consumables and nonconsumables) seem pretty elegant to me. However, I'm not sure how well they will work in case of permanently block traits.

For example, if Elegant is blocked, I guess the dress should still temporarily remove Aggressive while equipped. And don't forget about that problem with mutually exclusive traits and consumables I mentioned here. While I have proposed a solution, it's far from being elegant.

[Xela]

I see. Well, these solutions (for consumables and nonconsumables) seem pretty elegant to me. However, I'm not sure how well they will work in case of permanently block traits.

Blocked trait, either simple or permanent block will never be applied to a girl. We can throw a warning screen if any of the traits enforced by an item is permanently blocked or I can add an extra warning field so we don't mess the game up with warning screens.

For example, if Elegant is blocked, I guess the dress should still temporarily remove Aggressive while equipped. And don't forget about that problem with mutually exclusive traits and consumables I mentioned here. While I have proposed a solution, it's far from being elegant.

I think each equipable item's traits should reflect nature of an item and don't bother with what is blocked and what isn't. Consumables and misc might be different since a player may need to pay a lot of money/do a long quest to get a consumable item with trait effect or have a girl 'use' misc item for a really long time to get a trait but blocked traits will be reported in girl's profile screen when we design it properly, so it is up to player to keep track of things like that, best we can do, as I've said, is give a warning either onscreen or on a pop-up warning screen...

[DarkTl]

Btw, can I use subfolders for icons? Something like content/items/cons/*.png for consumables?

And in sex field in case of unisex should I write "unisex" or "uni"? I know I don't have to, since it will defaults to Unisex, but still 

[Xela]

Btw, can I use subfolders for icons? Something like content/items/cons/*.png for consumables?

And in sex field in case of unisex should I write "unisex" or "uni"? I know I don't have to, since it will defaults to Unisex, but still 

Sure, use whatever you're comfortable with, just make sure path is correct in icon field.

It's 'unisex'. Here is a class for an Item:

Code: [Select]

    ####### Equipment Classes ########
    class Item(Structure):
        def __init__(self):
            Structure.__init__(self, namespace=None)
            self.desc = ''
            self.mod = dict()
            self.max = dict()
            self.min = dict()
            self.addtraits = []
            self.removetraits = []
            self.addskills = []
            self.removeskills = []
            self.addeffects = []
            self.removeeffects = []
            self.goodtraits = []
            self.badtraits = []
           
            self.price = 0
            self.sex = 'unisex'
            self.infinite = false
            self.locations = []
            self.chance = 50
            self.badness = 0

           
           
        def init(self):
            if not self.has('slot'):
                self.slot = 'consumable'
           
            if not self.has('hidden'):
                self.hidden = true
               
            if not self.has('cmax'):
                self.cmax = false
               
            if not self.has('eqchance'):
                self.eqchance = self.badness
             
            if not self.has('type'):
                self.type = self.slot
               
            if self.slot == 'consumable':
                if not self.has('cblock'):
                    self.cblock = false

                if not self.has('ctemp'):
                    self.ctemp = false
                if not self.has('ceffect'):
                    self.ceffect = false
                   
            if self.slot == 'misc':
                if not self.has('mtemp'):
                    self.mtemp = 10
                if not self.has('mdestruct'):
                    self.mdestruct = false
                if not self.has('mreusable'):
                    self.mreusable = false


[DarkTl]

so it is up to player to keep track of things like that, best we can do, as I've said, is give a warning either onscreen or on a pop-up warning screen...

I agree. Also, we could make warning screens customizable, so players could decide which warnings they need and which don't.

[Xela]

I agree. Also, we could make warning screens customizable, so players could decide which warnings they need and which don't.

That's actually very easy since we already have a flog system in place. I'll see if I can put some time into guard job tonight, still hate that bit of code but recently learning couple of new tricks, it should progress much faster now

[DarkTl]

Xela, since we don't have shops and locations, could you create some kind of mechanism for items testing? Like, any item with location name = 'Item Shop' will be in Hinata's inventory when you start a new game or something.