General Discussion

[Xela]

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

Sure, go ahead.

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

I am not convinced that it's a bad thing. The system seems to work perfectly fine, it can be improved but prolly not in the direction you're suggesting.

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 

Once again.... why? You'll have to give me an example where this goes wrong.

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

Joy can be prolly added there as well.

[DarkTl]

Isn't there a difference in terms of speed between filtering out non restore non food items and have 27 to look for mod health, and don't filter them out and have 77 items?
Also, assuming that we'll have drugs and alcohol, it might be useful to set cases when characters begin to use these types of consumables via auto equipment more strictly.

Btw when you run

                if self.health < 60:
                    l.extend(self.auto_equip(["health"]))

during next day calculations, it's wiser to limit it to consumables and maybe miscs, unless you want to equip items that increase max health too.

[Xela]

Isn't there a difference in terms of speed between filtering out non restore non food items and have 27 to look for mod health, and don't filter them out and have 77 items?
Also, assuming that we'll have drugs and alcohol, it might be useful to set cases when characters begin to use these types of consumables via auto equipment more strictly.

Btw when you run during next day calculations, it's wiser to limit it to consumables and maybe miscs, unless you want to equip items that increase max health too.

Ok, I'll try to come up with an adaptive way to provide more fields for sorting...

[DarkTl]

To clarify, autoequipment already has slot argument. But I'm not sure if it works like I think it does, because comment for it is "slot: slot" 

[Xela]

To clarify, autoequipment already has slot argument. But I'm not sure if it works like I think it does, because comment for it is "slot: slot" 

It works on "per slot" basis, so when you call the method, you provide just the one slot, all other items are being filtered out. I wanted to make one method for all slots eventually, but code got too confusing and it was working very slow, prolly due to too many nested loops. I can prolly do better now but the method is already fairly complicated.

[DarkTl]

Ahh. I thought it can take as many slots as needed, and was wondering why sometimes this opportunity is not used in the code.
It's not a problem, of course.

[DarkTl]

Eh. You make skill checks by passing name of skill as a single string. That excludes using more than one skill per job and different formulas, I'll have to rewrite it.

[Xela]

I don't remember, feel free to adjust the code, I will not have a lot of time before evening...

[DarkTl]

Usually we check traits like if "Shy" in char.traits. But inside jobs you check it like if traits["Virgin"] in self.worker.traits.

I'm confused about traits[] part, why you didn't used if "Virgin" in self.worker.traits?

[Xela]

Usually we check traits like if "Shy" in char.traits. But inside jobs you check it like if traits["Virgin"] in self.worker.traits.

I'm confused about traits[] part, why you didn't used if "Virgin" in self.worker.traits?

At first we worked just with strings, later I rewrote the system and switched to object so for a while it was impossible to check for string. Now I've added extra check through special method overrides, if we check for string, object will be created internally. Basically both options are perfectly fine now.

[DarkTl]

I can't believe python doesn't have case switchers because the devs feel like they are not needed, unlike other languages...

Together with the lack of labels support it loves to lead me into making super long and complex elif checks 

[Xela]

I can't believe python doesn't have case switchers because the devs feel like they are not needed, unlike other languages...

Together with the lack of labels support it loves to lead me into making super long and complex elif checks 

Yeah, screw those guys 

You can write a bunch of function/custom class to work as switches, if/elif/else will work as well obviously. If you are not doing it for the jobs (any Python code), you can use Ren'Py's labels to a similar effect.

===
I finally have some free time today, maybe like 5 or 6 hours if nothing comes up like it always does... I'll try to hack on jobs for a bit and maybe start working on SE or continue with BE if I get sick with it. I have a lot of stuff to change/improve in the BE and nothing's been done n the new SE yet (old one was working perfectly thought)...

Edit:
Well, something came up but I have managed some nice cleanup + renaming + refactoring of the business code. This is a very important step towards improving the execution. I'll try to put a few more hours into in tonight.

[DarkTl]

Do you think simpy can handle dates as well in the future? Something like SE, but with other types of events and checks.

[Xela]

Do you think simpy can handle dates as well in the future? Something like SE, but with other types of events and checks.

That may not be useful. There is one major limitation in SimPy/Ren'Py combo:

- We cannot keep any instance related to SimPy between Ren'Py statements. That is due to limitations of Ren'Py, there may be a way around that but I did not have yet the time to test it yet.

===
That said, I am not sure what advantage we'll gain by using SimPy during dates. SimPy greatest advantage is ability to run any number of processes at the same time. In jobs advantage is obvious, while previously we had plain and linear execution like in all other games (that I've read code for), now we have processes for handing client movement in the building between businesses, client process within every individual business within one building, workers processes when required and businesses management processes when required. Everything SimPy does was possible to achieve with while/for/if/elif/else but that would require thouthands of lines of unmanageable code (I've tried that approach wasting 2 full days of coding on it, just to realize that even if I get it right, it will be impossible to properly work such a shitty system that would have taken me many month to complete).

SimPy does that in a really simple and convenient manner, but it's coding style takes getting use to because I've only worked with linear progression in the past.

In BE, SimPy can handle the graphics better. In SE SimPy really shines because I couldn't even manage coming back after an exploration run code before (all traveling time was taken off at the beginning) without really, really sh!tty code. That is something SimPy does by default and without any issues, other cool stuff like teams helping each other out when exploring in the same area is also now possible without too much fuss.

Dates on the other hand are linear, you have no one competing against you and no one dating at the same time so what/how SimPy can be of any help there is unclear to me.

[DarkTl]

Everything SimPy does was possible to achieve with while/for/if/elif/else but that would require thouthands of lines of unmanageable code (I've tried that approach wasting 2 full days of coding on it, just to realize that even if I get it right, it will be impossible to properly work such a shitty system that would have taken me many month to complete).

That's what I mean. I figured simpy also makes checks for multiple events simpler.