General Discussion

[DarkTl]

source: list of inventories to draw from (We assume that only consumable items are to be equipped from other inventory than that of an instance of self)

I don't understand this one in context of autoequipping.
Do you allow chars to share consumables or something?

[Xela]

I don't understand this one in context of autoequipping.
Do you allow chars to share consumables or something?

Exactly that, I wrote that bit for old SE. Imagine one teammember getting beat up/out of MP bad and finding herself out of potions. If teammembers have them available, why not allow sharing between teammates?

[Xela]

About speed, to shuffle quite big lists when we need just to randomly pick a few different elements from them seems unreasonable. I wonder if there is a better way.

Nope, what we use is generally the best, most "pythonic" and fastest way.

Alternative is:

Code: [Select]

list.pop(random.randrange(len(list)))
But it looks sh!tty and will get slower really fast in comparison with:

Code: [Select]

shuffle(list)
list.pop() # as many times as needed.
I've researched this one couple of years ago, it has to do with how arrays are implemented in Python, removing/returning any item from middle of the list is a very expensive operation compared to getting one from the end of the same list. If you need to do it once, alternative is prolly a better option, if you need to do that a number of times, what we use quickly becomes a lot faster.

[DarkTl]

That's a lot of removed code. Don't tell me you gave up on that simpy thing.

[Xela]

That's a lot of removed code. Don't tell me you gave up on that simpy thing.

Jobs would have immediately stopped working and fall apart if I did. That bit of coding was me partially rewriting SimPy when I couldn't get it to work initially with Ren'Py (there were a couple of serious obstacles there), now that they cooperate, that code is prolly completely useless. SimPy itself is pure python loaded as a module.

[DarkTl]

$ auto_buy_items = [item for item in shop_items if item.usable and not item.jump_to_label]

What item.usable means?

[Xela]

$ auto_buy_items = [item for item in shop_items if item.usable and not item.jump_to_label]

What item.usable means?

Code: [Select]

        NOT_USABLE = set(["gift", "quest", "loot"])
        NOT_TRANSFERABLE = set(["gift", "quest", "loot"])
        NOT_SELLABLE = set(["quest"])
        CONS_AND_MISC = set(['consumable', 'misc'])
bound directly to item's class. Basically means that such a item cannot be consumed or equiped.

[DarkTl]

        def equip_for(self, purpose):
            """
            This method will auto-equip slot items on per purpose basis!
            """
            returns = list()
            if purpose == "Combat":
                if self.eqslots["weapon"]:
                    self.unequip(self.eqslots["weapon"])
                for slot in self.eqslots:
                    if slot.startswith("ring"):
                        slot = "ring"
                    if slot != "consumable":

Why do you unequip weapon here?

[Xela]

Not sure... it was a long time ago.

Maybe because I wanted to include the equipped item to choices when reeuipping or I wanted to clear stats so it would be easier to pick the best item... if it's the latter, it may actually not be a bad idea to unequip all items except for misc...

[DarkTl]

It's weird because you unequip only weapon, and you do it for all purposes including combat. So it cannot be a measure against equipping big weapons by non warriors, and at the same time you don't touch other slots 

You have that comment

            # The idea is to increase any particular stat to it's maximum
            # Maximum raising should be coded in at some point as well

and then this code

# We do the same thing for max stats:
                    for stat in item.max:
                        if stat in self.stats: # Not useful?
                            if item.max[stat] > 0:
                                possible_bonus += item.max[stat]
                                if stat in target_stats:
                                    # This is not perfect, but it shouldn't matter (max at the game start issue)
                                    if self.stats.max[stat] + item.max[stat] < self.stats.lvl_max[stat]:
                                        bonus += max(0, item.max[stat])
                                        # For equippables, we want this to triple as being extra useful!
                                        if slot not in ["misc", "consumable"]:
                                            bonus = bonus + item.max[stat] * 2
                                    else:
                                        bonus += max(0, self.stats.max[stat] - self.stats.lvl_max[stat])
                            else:                               
                                if stat in exclude_on_stats:
                                    penalty += item.max[stat]

So max is properly coded atm after all?
I believe autoequipping requires some optimization too, at very least you use there & instead of intersections.

Also, I suppose we could use a separate algorithm and a function to take care about restoring health, mp, vitality and joy. Since we don't have to increase max or use the best possible one there.
 

[Xela]

So max is properly coded atm after all?

"properly" is not the right word here It's taken into consideration... the best way it could be done at acceptable speed.

The trouble with a system as complicated as ours is that there is no good + fast way of prioritizing items by code. The only perfect way of doing that is what I use in equipment screen but that is very, very slow and absolutely unexceptable for a method that we may run during next day.

If not by hand, I do have one more idea on how to improve it... but I'll have to do it myself.

===
So we compromise, somewhat poorly... but it should work well enough. Other option is to do that by hand, assigning "levels" to items and using just that. That would be the fastest way. Consumables are simpler to work with and even right now we usually get them right.

I believe autoequipping requires some optimization too, at very least you use there & instead of intersections.

Lots... but from what I've read from professionals, the idea is to write the code, make sure it is working ok and rewrite as many times as required. My original version was too slow but this one seemed fine. I obviously go over old code every now and again trying to improve it when I don't have enough time to write new code.

Also, I suppose we could use a separate algorithm and a function to take care about restoring health, mp, vitality and joy. Since we don't have to increase max or use the best possible one there.

I think it already works like that... at least it is supposed to.

[DarkTl]

I think it already works like that... at least it is supposed to.

I don't think so... For a start, I don't see where you exclude restoring items from max part for example.
Besides I don't see a single mention of joy in the code, while some items have a great impact on it, yet its mechanics are close to vitality.



Also there is a difference between using consumable stuff such as makeups for increasing charisma and restoring health.
There is no reason for us to not use temp consumables like makeups unless  current charisma=max possible charisma already. More charisma always means more income in theory.

But if we have 99/100 health, it would be wise to ignore it. It's ok to have not 100% of health all the time, not to mention vitality or mp. In general we don't have to try to restore them completely, 85-90% should be enough.
 
If we have 80/100 health, it would be wise to use some food to restore it. If we have 70/100, it would be wise to use a small potion which restores 25 points or food. If we have 40/100 health, we use should try to use medium or two small ones before using better ones. If we have 1/1000, it would be wise to use ultimate healing potion.

I'm writing it because I'm not able to code it on my own, of course 

[Xela]

I'll try to take a look at that tonight if time allows.

Edit: I am too tired for a method this complicated Gonna read it through a couple of times and make more comments, I'll prolly be busy for the next couple of days as well.

[Xela]

I tweaked the method best I could for now...

I don't think so... For a start, I don't see where you exclude restoring items from max part for example.
Besides I don't see a single mention of joy in the code, while some items have a great impact on it, yet its mechanics are close to vitality.

We don't exclude restoring items based on max, I am not sure why would we want to.

Stats are provided to the method, that's why you do not see them mentioned internally.

Also there is a difference between using consumable stuff such as makeups for increasing charisma and restoring health.
There is no reason for us to not use temp consumables like makeups unless  current charisma=max possible charisma already. More charisma always means more income in theory.

There is... and logic for that seems decent.

But if we have 99/100 health, it would be wise to ignore it. It's ok to have not 100% of health all the time, not to mention vitality or mp. In general we don't have to try to restore them completely, 85-90% should be enough.

It worked fine with my tests and I've tested this method extensively but this can be easily added.

If we have 80/100 health, it would be wise to use some food to restore it. If we have 70/100, it would be wise to use a small potion which restores 25 points or food. If we have 40/100 health, we use should try to use medium or two small ones before using better ones. If we have 1/1000, it would be wise to use ultimate healing potion.

It already works this way. Maybe I even managed to improve it a little bit but it seemed to be working flawlessly even before that.

===
I'll push a bit later.

[DarkTl]

Can I modify skills and stats checks and lines for them inside jobs?
Or you have some simpy-related plans for them?

We don't exclude restoring items based on max, I am not sure why would we want to.

If we want to heal the character and call the autoequipment function with self.auto_equip(["health"]), we follow the usual algorithm which:
1) includes finding the best max too, not just make current health close to max health
2) is not limited to restore and food items types

And both things are useless for restoring health, so turns out we do useless calculations. I suppose at very least auto_equip function could use not just slot, but also a list of items types as arguments, even if finding max will remain because you want it 

Stats are provided to the method, that's why you do not see them mentioned internally.

                        l = list()
                        if item.statmax:
                            for s in item.mod:
                                if s in self.stats:
                                    if s not in ["vitality", "health", "mp", "gold", "exp"]:
                                        if self.stats < item.statmax:
                                            l.append(True)
                                            break

Here you have a list of excluded stats. I believe joy should be here too, unless I misunderstood something.