General Discussion

[DarkTl]

There are some large items icons as well but I doubt that it matters much as long as we predict the images well.

It's not true. I resized all items icons to 200x200 a long time ago, with the exception of a few special items which may or may not stay in the game, and even they are not much bigger than 200x200.

And redownload all packs already instead of fixing girls sprites by yourself, thus repeating my job 
I'm not planning to improve existing ones any more, unless there will be a major error or another global retagging, so it's pretty safe to download them at this point. Characters data files aside of course, but they are not a part of packs archives.

This however is awesome because once I can count on all sprites working under the same rules, I can try out new stuff to account for inconsistencies.

Some mobs should obviously be larger than others. I suppose mobs could use size string or something, like height for characters.

There are still some frecked up MC images I think, but it's no longer frequent event that I cross one of those (i resized some of those myself in the past).

I'll take a look tonight.

2P attacks are messed up at the moment and will require some rewriting (animation times that I wanted to handle with SimPy before).

Also iirc p2p attacks don't support sprites shaking.

[Xela]

It's not true. I resized all items icons to 200x200 a long time ago, with the exception of a few special items which may or may not stay in the game, and even they are not much bigger than 200x200.

And redownload all packs already instead of fixing girls sprites by yourself, thus repeating my job 
I'm not planning to improve existing ones any more, unless there will be a major error or another global retagging, so it's pretty safe to download them at this point. Characters data files aside of course, but they are not a part of packs archives.

Forgot about that item files were already resized appropriately.

I'll get the packs.

Some mobs should obviously be larger than others. I suppose mobs could use size string or something, like height for characters.

Maybe, first a plan is needed that will take care of as many issues as possible. Then mobs can be updated properly for the release.

Also iirc p2p attacks don't support sprites shaking.

I want to write proper, reusable code for all attacks but first thing on the list for tonight is to figure out why attacks are CPU dependent, I already have an idea. Maybe laptop (really good hyper-threaded quad) is actually faster then desktop (hyper-threaded duo). There may be a small, easy to fix flaw in my UDD design for Animation. If not it's the calculation but once we use there are so simple the should take nano-seconds which should not effect anything at all.

[DarkTl]

In some jobs you have this stuff:

            for stat in self.locmod:
                if stat == 'fame':
                    self.loc.modfame(self.locmod[stat]) 

which (probably) should increase fame of the building.

In other jobs you do it like self.locmod['fame'] += choice([0, 1, 1]), which increases building fame for sure.

Should I change it to locmod everywhere?

[Xela]

In some jobs you have this stuff:which (probably) should increase fame of the building.

In other jobs you do it like self.locmod['fame'] += choice([0, 1, 1]), which increases building fame for sure.

Should I change it to locmod everywhere?

That may not work everywhere... I don't remember how the code is setup but from my most recent update dict should no longer be preset.

Code: [Select]

self.logloc("fame", choice([0, 1, 1]))
is the new "correct" way although it's a bit slower due to function call. Fastest way is prolly:

Code: [Select]

self.locmod["fame"] = self.girlmod.get("fame", 0) + value
but it's a pain to copy-paste it everywhere for actor and building stats. loggs and logloc methods do the very same thing and look better.

[DarkTl]

We probably check database too much... Every sex act checks for multiple tags combinations every time. And I do it in interactive sex scene too, though it's not so bad compared to jobs.

I suppose we should check all needed combinations once and make a dict with existing ones or something.

[Xela]

I suppose we should check all needed combinations once and make a dict with existing ones or something.

We could, I even wrote some base code for that but it's simpler the way we do it now. Also those checks are really, really fast. We'll do it as you say eventually, but now there is stuff of higher priority.

Edit: Code was for a system we no longer use/have, but it is a straightforward dict so it's not a big deal.

[DarkTl]

What's the difference between self.worker.refinement and self.worker.get_skill("refinement")?

[Xela]

What's the difference between self.worker.refinement and self.worker.get_skill("refinement")?

self.worker.get_skill("refinement") will return the true, final skill with all logic applied.

self.worker.refinement This is just the action part without any mods.

[DarkTl]

Alright, the whore job is close to be finished. I want to add group actions as well, but that requires actual logic at the level of customers, when they either form a group or come as a group.

Since we never did anything about changing strings depending on genders (only talked about it once), I ended up with passing customer gender to checking function, and then selecting line depending on it.

[Xela]

Alright, the whore job is close to be finished. I want to add group actions as well, but that requires actual logic at the level of customers, when they either form a group or come as a group.

Since we never did anything about changing strings depending on genders (only talked about it once), I ended up with passing customer gender to checking function, and then selecting line depending on it.

self.client.gender returns the proper gender. As you've prolly noticed, all clients are male atm. They now all have names as well. (there are no issues with female once, they are just not created right now).

Edit:
Too tired for proper coding tonight, I'll take a look at CPU BE thing, it's not the graphics themselves, I know that now.

[DarkTl]

We do have lesbian acts, which are hard to imagine without females involved 

Edit: 555s commit is mine 

[Xela]

We do have lesbian acts, which are hard to imagine without females involved 

I know, code for creating female customers should be complete, it's not hard to add the to actual generation. I just didn't care about that much before coming up with actual, conditioned costumer generation.

Edit: 555s commit is mine 

Congrats, I played around with BE a bit but was too tired to get anything done for real.

[Xela]

After a lot of useless messing with SimPy/loops and/or timers I've prolly have figured out a decent way (more like a coding concept) to manage it all. I'll try to make it all work tonight and standardize the code across all attacks.

[DarkTl]

If customers already pick characters depending on preferences, you should add it to reports too because it's kinda interesting.

We could use more texts for various sex actions to use with choice ("wrapping around so tight...", etc), but it's not something I can do, I always was bad with THAT kind of texts no matter the language 
And in wm lines are a bit comical and surreal, so I'm not sure where to look for this stuff.

I also created an issue for customers generation. Bdsm will wait for adding ST, but groups we already can add.

[Xela]

If customers already pick characters depending on preferences, you should add it to reports too because it's kinda interesting.

I have... it's being reported to the main report, we should prolly move that through flags to detailed report later.

I also created an issue for customers generation. Bdsm will wait for adding ST, but groups we already can add.

Oki, I'll add that first when I can (it's an easy operation for female but groups require a bit of thinking through so that'll have to wait, it's not that it's difficult or anything like that, it's just that we do not currently have a system setup for that).