1) read XMP metadata from the image file and remember which file paths are tagged with which tags; the classes associated with my ImageDatabase class do that;
2) A simple request could be:
img = imgdb.get_image("sex - blowjob", "character - Asuka")
In Pytherworld, I create a group of tags that describes the image I am looking for. For example, the code that selects a picture for a character that shows this character being sold at a slave auction:
required, bonus, excluded = character.get_tags()
bonus.add("other clothing - nude")
bonus.add("sex - bondage")
bonus.add("indoor - basement")
sextags = core.tagini.get_tags("sex", categorized=True)
sextags.remove("sex - bondage")
sextags.remove("sex - lockdown")
sextags.remove("sex - touch")
excluded.update(sextags)
excluded.add("misc - generic")
excluded.add("misc - portrait")
imgctrl = core.imgdb.select_image(required, bonus, excluded)
This code results in a search for a picture that fulfills the following conditions:
* It shows the character
* The character is not participating in any activity of the sex category, except for "sex - bondage", "sex - lockdown", or being touched
* The image is no generic image and also not a portrait
* Images where the character is nude, in bondage and in a basement-like location are preferred
Selecting a picture like that is hard to do with your system, unless you create a specific category for that. However, each additional category in your system means additional image files to copy and rename. An additional category in my system can be added as an afterthought without any involvment from the girlpack authors. Just select a combination of tags and you have created a new category.
I wonder how a XMP parser works... maybe it would be possible to do this?:
This is from an instance of sGirl class:
u'shop': [u'content/chars/naruto/Hinata/shop (2).jpg', u'content/chars/naruto/Hinata/shop (3).jpg'
method of the same class calls a category (shop) and randomly chooses an image from the list.
----------------------------
What if during the creation of an instance, we also read XMP tags and created a dict with picture path being a key and tags being values (another list).
Then we edit method as well, call it with a new kwarg 'tags' that goes through all images in shop category and tried to find the best match for the situation. This way almost nothing would have to be changed in game makeup and we would have a system that is not quite as powerful as the one in PytherWorld but still packs some heat and offers a good deal of possibilities.
PS: Renaming pics is easy in batches, I have a whole system for that.
My tagging system is a lot more powerful than the system we use here in PyTFall. It is also more complicated though. Since you are obviously convinced the current PyTFall system is good enough, I suggest we stick with it. I don't care either way as I don't have to work with it ;-)
I once wrote a post about game 'generations'. I don't remember where but the idea was:
First Generation Hentai Indie Sim Games:
SimBrothel
Slavemaker
Hentai Highschool
They had a fairly straightforward interface and logic and allowed none to little moddability.
Second Generation Hentai Indie Sim Games:
SlaveMaker 2
WM
SimBro 1x
These allow much better moddability, better graphics (In some cases), more advanced logic.
Third Generation Hentai Indie Sim Games:
SlaveMaker 3
OtherWorld
These allow unreasonable possibilities for moddability, better logic, more content and so on.
As you can see, WM and SimBrothel are missing from the list of third generation, because WM2 has never been created and all SimBrothel project that tried to climb up there failed miserably.
So my objective is to build a third generation SimBrothel and WM, with advanced job system where jobs effect one another, social system, slave training and multiple stat/skill variations, battleengines, quests, events and missions, highly graphical interface. I don't want to be sidetracked by making it to advanced, simply because there will eventually be Fourth generation at some point that might have even better jobs system, near perfect image handling, better quests system and so on. Maybe after I am finished with PyTFall projects, I will build a game like that, but for now I don't want to spend to much time on features that are overcomplicated.