General Discussion

[Xela]

Alright, then we need to decide how fast skills will grow without using powerful items. I believe you mentioned something like 1-2 per day at best, which means 5.5 years for 2000 and 13.5 years for 5000.
Are you sure about it?

I'd prefer 4 years without traits/items to 2000... I don't think it's too much of a stretch. Class traits should speed that up along with some normal traits + items should have effect as well.

We should have many chars in the game that are already skilled and expensive to hire/buy. Training should not be doable in a couple of month, at least not proper training.

[DarkTl]

You have pretty low checks inside jobs then...

Not sure what to do with lesbian either. We cannot keep using vaginal for everything. I suppose I could make it use skills depending on selected action, unless you have a better idea.

[Xela]

We'll fix the levels.

On the acts front, I think those would have to be separated to their own method and called/passes from the building.

[Xela]

I found more broken VBoxes in the Arena (pretty much all of them in ladders and etc.). The one on the city map screen is now fixed!

Arena should now also be fixed, if there are more, I haven't found them yet. This is it for the day...

[DarkTl]

Code: [Select]

            Do we get the most needlessly complicated skills system award?
            Maybe we'll simplify this greatly in the future...

C'mon, it's not nearly as complicated as in some other games 

For example in Sims skills there have their own small traits gained if you do something related to the skill many times. In our case it would be something like "Master of Anal" for anal skill if the character did it 500 times, which increases income and joy bonus for anal sex.

[Xela]

We'll prolly have that as well, it's traits/jobs, not really skill related.

[DarkTl]

I'm not sure how to do it properly.

if self.inventory:
                    hasitems = set(list(items for i in self.inventory))
                else:
                    hasitems = set()
                for key in self.eqslots:
                    if self.eqslots[key]:
                        hasitems.add(self.eqslots[key])

This is your code that returns a list of existing items in character inventory.

How to check if there is at least one item with "body" slot in the list?

[Xela]

You have an error in that code, items for i in self.inventory will not build a useful set.

Otherwise, to check (after we got hasitems set):

Code: [Select]

if any([i for i in hasitems if i.slot == "body"]):
    # We have at least one item with body slot.
in 99% if all cases we work with objects, that is usually bloody useful, fast and convenient.

[DarkTl]

You have that comment there, "This assumes that a free! girl! is buying". Is there anything that prevents us from allowing trained slaves to use shops if you give them money, like in SM?

[Xela]

You have that comment there, "This assumes that a free! girl! is buying". Is there anything that prevents us from allowing trained slaves to use shops if you give them money, like in SM?

I don't think so but there is no check against weapons. Before politics module wish can be used to change rules of the game, we assume that slaves are not allow to carry weapons.

It may be weird if a "bazooka" is bought in such a context.

[DarkTl]

Alright, I reworked autobuying. See if you can optimize it, some checks are quite long.
It's even ready for slaves, though they for a start require a rules screen like the one SM has, where you can decide if they can go to shops or not.

Also it's possible to make it smarter by buying needed consumables, like with low health they tend to buy health restoring items. If you think it's needed, you can show me how to check if an item has a positive "health" value in its mod 

[Xela]

I'll take a look

Edit:

Looks alright. I've fixed some stuff so it runs a tiny bit faster but nothing stood out logic wise except for one bit where I left you comments (self.occupation is almost always longer than one element because even just the "Warrior" will add two elements there: traits["Warrior"] (object) and "Warrior" (string (generalization for simple checks))). set.intersection is generally faster than my old "&" and we no longer convert anything to sets which is a lot faster.

Small things but I've seen decent code improving execution speed by 4 times (simple improvements, using code that is executed in C and etc.). In one case it was a whooping 20 times (in PyTFall) but that was an example of really poor coding on my part (complex calculation that only had to be done once found it's way in a long, double for loop).

[DarkTl]

I don't like how all characters follow the same pattern, visiting shops strictly if self.flag("day_since_shopping") > 5. It probably could be trait based.

Is there any difference in terms of speed between if ((a>b) and (c>d)) and if all(a>b, c>d)?

[Xela]

I don't like how all characters follow the same pattern, visiting shops strictly if self.flag("day_since_shopping") > 5. It probably could be trait based.

I try to randomize the days as much as possible so they are not shopping on the same day. Shopping should also not activate when chars are working. You can tweak and twist that as you want, we'll may even introduce shopping events in the future

Is there any difference in terms of speed between if ((a>b) and (c>d)) and if all(a>b, c>d)?

Code: [Select]

if a>b and c>d:
    # Do something...
is faster for sure. I actually think that any()/all() are only faster when you have a prepared container for them to work with, otherwise they would have to build generators/containers before execution and that will always take some time. The reason I use sometimes use them is better readability and in places where we don't give a sh!t about speed (stuff that just runs during gameplay in labels is close to impossible to overload with logic on modern machines and old machines ). Anything during the Next Day is the most brutal... In future we can sneak some calculations while the player is just playing the game (move them from ND) but that kind of optimization is in distant future.

===
But this will not matter a lot in this case. Best improvements are when you can fix plainly bad coding and/or move stuff to modules that are executed in C which is always much faster.

[DarkTl]

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.