General Discussion

[Xela]

Do we keep slaves running away events for beta? Because we have a few items left from the ST attempt which give Restrained trait, it should prevent escaping in theory.

I was looking into that but code is a bit confusing. It feels like we should but I am going to do tiers/jobs first. Tomorrow is pytfalls time, got a headache from working on BR today.

Tool to help with directing:



there are too many expressions to remember. Any portraits can be clicked to send corresponding script to clipboard so it can be copy-pasted to editor.

[DarkTl]

Classes-training.rpy is insanely big and complex, considering that it just handles ST and a very small part of schools.

Code: [Select]

        def __init__(self, mod=None, min=None, max=None, props=None, flags=None, traits=None, noTraits=None, effect=None, noEffect=None, funcs=None):
            """
            Creates a new PytStatCheckCheck instance.
            mod = A condition dict to match stats or skills.
            min = A condition dict to match minimum stats.
            max = A condition dict to match maximum stats.
            props = A condition dict to match character properties.
            flags = A condition dict to match flags.
            traits = A list of traits needed.
            noTraits = A list of traits that aren't wanted.
            effect = A list of effects needed.
            noEffect = A list of effects that aren't watned.
            funcs = A list of functions to call.

            mod, min, max, props and flags shoud be formatted as:
            {
            "lt": An object of {"stat": number} keys to match a < condition.
            "le": An object of {"stat": number} keys to match a <= condition.
            "eq": An object of {"stat": number} keys to match a == condition.
            "ne": An object of {"stat": number} keys to match a != condition.
            "ge": An object of {"stat": number} keys to match a >= condition.
            "gt": An object of {"stat": number} keys to match a > condition.And I'm not a fan of checking conditions using special keys, it works much better in quests system where you can just pass usual condition string...

[DarkTl]

We need an item field which makes items equipable only on slaves, just like gender field does it for genders. Even without ST we have some items that free chars should never agree to use.

[Xela]

We need an item field which makes items equipable only on slaves, just like gender field does it for genders. Even without ST we have some items that free chars should never agree to use.

Don't we have badness for that?

I am suffering from splitting headache since morning. Gonna try coding something if it goes away, but do you think it's a good bet to mess with logic like item transfer/equipment before beta? That seems to be pretty stable right now.

[DarkTl]

Lover status and very high disposition overwrite badness. They overwrite almost anything except bad traits. You can effortlessly chain free chars with high disposition.
On the other hand Picobyte wrote interesting algorithm for autoequipment, perhaps it could be used for manual equipment too, I'll look into it.


It's not normal to have regular headaches btw, it usually means lack of blood supply to the brain, and should be treated, not endured. I know what I'm talking about, proper treatment helps (real treatment, not alcohol  )

That being said, I do hope it means the "pytfalls time" will be the next time you gonna code, not only after another BR session which can give you another headache, killing any progress whatsoever.

[DarkTl]

Yeap, now eqchance 0 makes items unusable/unequipable manually, unless slave status or good traits are involved.

I especially like these part in new items algorithms added by Pico:

Code: [Select]

            for trait in self.traits:

                if trait in trait_selections["badtraits"] and item in trait_selections["badtraits"][trait]:
                    return None

                if trait in trait_selections["goodtraits"] and item in trait_selections["goodtraits"][trait]:
                    chance.append(100)

                if trait == "Kamidere": # Vanity: wants pricy uncommon items
                    chance.append((100 - item.chance + min(item.price/10, 100))/2)

                elif trait == "Tsundere": # stubborn: what s|he won't buy, s|he won't wear.
                    chance.append(100 - item.badness)

                elif trait == "Bokukko": # what the farmer don't know, s|he won't eat.
                    chance.append(item.chance)

Code: [Select]

            for t in self.traits:

                # bad eyesightedness may cause inclusion of items with more penalty
                if t == "Bad Eyesight":
                    min_value = -10

                # a clumsy person may also select items not in target skill
                elif t == "Clumsy":
                    target_skills = set(self.stats.skills.keys())

                # a stupid person may also select items not in target stat
                elif t == "Stupid":
                    target_stats = set(self.stats)

                elif t == "Smart":
                    upto_skill_limit = TrueI never thought about using traits as modifiers for equipment chances.

[Xela]

I think we'd be mimicking functionality... if you are going to add the some form of new blocking field for slaves, maybe something like:

Code: [Select]

"blocks_equipping": ["slave"]
So we could add traits or other flags there as well?

[Xela]

It's not normal to have regular headaches btw, it usually means lack of blood supply to the brain, and should be treated, not endured. I know what I'm talking about, proper treatment helps (real treatment, not alcohol  )

That being said, I do hope it means the "pytfalls time" will be the next time you gonna code, not only after another BR session which can give you another headache, killing any progress whatsoever.

It's not that simple... my "house-doctor" that gives out "directions" to specialists is 400km away cause we moved to a different city. You can get a new one only on last week of December and July. Plus I am pretty sure this sh!t is due to lack of normal living routine which should get better soon, rest of the furniture comes in on Friday and everything major in the house should be finished this weekend.

I've ordered new pc rig as well, gonna be here tomorrow if they don't f*ck something up. Once I can keep normal hours nest week, I'll do two dev sessions a day, in morning and in evening, keeping br-pytfall-br-pytfall-... in mornings and do simple sh!t in evenings whereever they may be needed.

[Xela]

considering that it just handles ST and a very small part of schools.

Yeah... I think it needs to be written anew because of that. Rewriting code like that take (in my case) 3 - 5 times longer that it would take to write a new design based of old data/content. We can't afford huge body of complicated code doing simple things anyway, not in a project this large.

Don't know if this should be done before or after beta. Everything seems to be working just fine in schools and we don't mess with ST atm.

[DarkTl]

Yesterday evening I already limited slaves-only items by giving them 0 equipment chance and changing the code. Before it only affected autoequipment, now any item with 0 or less eqchance cannot be equipped manually on free chars no matter the disposition, which makes sense since we also allow good items with 70+ eqchance to be freely equipped.

It doesn't solve the problem with items from ST though: either you make sure running away works and items that prevent it work too, or I remove all ST-related items until ST rewriting, which will happen after the beta. Because during beta they will just confuse everyone.

[DarkTl]

Yeah... I think it needs to be written anew because of that. Rewriting code like that take (in my case) 3 - 5 times longer that it would take to write a new design based of old data/content.

As far as I understand, it was written to support free-for-all ST, when you can have 100 slaves trained by 200 different characters without even involving MC himself.
I played only one game with a similar concept, Otherworld. And its development ended very badly 
WM doesn't count since you can have only one dungeon assistant there.

In ST, JoNT and several half-translated Japanese games that I played player still should actively participate in ST, it's never a mass, conveyor production. You still can have assistants, but they cannot train without the main character.

[Xela]

It doesn't solve the problem with items from ST though: either you make sure running away works and items that prevent it work too, or I remove all ST-related items until ST rewriting, which will happen after the beta. Because during beta they will just confuse everyone.

Ok, lets allow running away and items to prevent that for beta.

As far as I understand, it was written to support free-for-all ST, when you can have 100 slaves trained by 200 different characters without even involving MC himself.
I played only one game with a similar concept, Otherworld. And its development ended very badly 
WM doesn't count since you can have only one dungeon assistant there.

In ST, JoNT and several half-translated Japanese games that I played player still should actively participate in ST, it's never a mass, conveyor production. You still can have assistants, but they cannot train without the main character.

Still, i don't believe that code setup is justified. Original schools were coded really poorly and Thewlis basically fixed that bad design and build ST on top of it. I'll reevaluate it before rewriting but I am 99% sure that it would have to be done in the end.

[DarkTl]

You once proposed to use special lines for characters when you for example give them very good item. It's a bad design because it forces the player to click over that line every time.

But if such special lines are said without requiring additional actions from the player, then it's not a bad design any longer. Ie we don't use the narrator window and wait for mouse click, we show the line in a small window next to character sprite, it does not affect gui at all and disappears by itself after some time.

[Xela]

You once proposed to use special lines for characters when you for example give them very good item. It's a bad design because it forces the player to click over that line every time.

But if such special lines are said without requiring additional actions from the player, then it's not a bad design any longer. Ie we don't use the narrator window and wait for mouse click, we show the line in a small window next to character sprite, it does not affect gui at all and disappears by itself after some time.

Maybe a popup like quest notification is also an option here, but this can be arranged.

[DarkTl]

I mean something like that small dialogue window in the bottom left corner in last Atelier games.