<-- Archived --> *Image tagging concept

[livingforever]

Hey everyone!
Bad time to get a summer cold, but let's see how much I can get done today!

Considerations

• Level of detail
  Tags are supposed to descripe the situation in one word, everything else is most likely not important enough to be mentioned
• Gender differentiation
  Text descriptions (and therefore customers) aren't gender neutral
• Fallbacks
  A hierarchical fallback system should be in place
• Blocking
  If a tag without explicit fallback is not present, block the action
• Ease of use
  The tags should be intuitive and not overloaded
• Quick tagging
  All tags should fit on one editor page and should be grouped

First conclusions

• 1 & 2: Different tags for different customer types/genders are needed (at least externally)
• 2 & 3: The fallback tree is separated for each customer type
• 3 & 4: Defining the character's allowed occupations is no longer necessary - either an image with the parent tag for a job category is there or it's not
• 5 & 6: The concept is based on a bottom-up approach
• 2 & 5 & 6: The tagger hides non relevant tags or renames them based on the customer gender

First approach [notes]

• Prostitute [required, hidden, own text description]
• • Sex [hidden, own text description]
  • • Vaginal [not displayed for M/M]
    • Anal
  • MakeOut [hidden, own text description]
  • • Blowjob [displayed as "Licking" for F/F]
    • Handjob [displayed as "Fingering" for F/F]
    • Titjob [not displayed for F/F and M/M]
    • Footjob
    • Grinding
• Profile [required]
• • Freetime [character is resting]
  • Exhausted [auto-rest triggered]
  • • Injured [aggressive customer triggered]
• Beach [if no image present, character won't appear on the beach]
• (Other locations) [same as above]
• Fighter [if no image present, character can't have the profession]
• • Arena
  • (Others)
• (Other jobs) [same as above]

A few notes on the notes:
Required: At least one image with this tag is required for a character
Hidden: The tag doesn't need to be displayed in the tagger
Own text description: If the tag is used as fallback, the text description is also changed to be more general

Remaining problems
What about futas or customer groups? Differentiate between male and female interaction/groups or simply display multiple names for the same tag?

What if a slave is forced into a job with no fitting image present? Show a profile picture and a generic fail text or just don't allow the assignment?


First round of discussion
Go for it!

[CherryWood]

I believe that unless you want from Xela to recode the whole thing (good luck with that, I failed even when proposing a one function to read what tags are in chosen image  ), you need to make your concept more compatible with the game. Also something similar to what you call "fallback" and "blocking" is already in there.
-----


This is how tags work in Pytfall:

Code: [Select]

has_image(self, *tags):This function returns True is a girls has images with specified tags. Most of the jobs are coded using this, so the girl will not do something if she doesn't have an image for it.
Example:

Code: [Select]

if self.client.act == 'sex':
               
                acts = list()
                if self.girl.has_image("sex", "doggy"):
                    acts.append("sex_doggy")
                   
                if acts:   
                    act = choice(acts)
                else:
                    act = None


                elif act == "sex_doggy":
                    self.txt.append("He ordered %s to bend over and took her from behind. \n"%self.girl.nickname)
                    self.img = self.girl.show("sex", "doggy", resize=(740, 685))


                else:   
                    self.txt.append(choice(['He wanted some old-fashioned straight fucking. \n']))                    self.img = self.girl.show("sex", resize=(740, 685))one position from Whore job report
-------------
Show method we use to display images by tags

Code: [Select]

show(self, *tags, **kwargs):
            '''Returns an image with the supplied tags.have 3 types of possible behaviors

Code: [Select]

types:
                     - normal = normal search behaviour, try all tags first, then first tag + one of each tags taken from the end of taglist
                     - any = will try to find an image with any of the tags chozen at random
                     - first_default = will use first tag as a default instead of a profile and only than switch to profileand it's also possible to exclude any tags from the search
Examples:

Code: [Select]

chr.show("nude", "simple bg", type="first_default", exclude=main_sex_tags) to show a nude pics in girlmeets

Code: [Select]

self.girl.show("maid", "cleaning", "cooking", "bunny", "waitress", exclude=main_sex_tags + ["strip"], resize=(740, 685), type="any") images for service course

Code: [Select]

show("bikini", "beach", "swimsuit", exclude=for_gm_selection + all_indoor_tags + ["pool", "onsen", "winter"], type="any") current beach girlmeets




There are some flaws, but this is what we have now. (a few pages back you can find a post where I tried to explain what the main issue is)
I'm sorry if you know all of this, but what I want to say is, that talking about tags now is not making something out of a blue but improving, so your concept would be much easier to understand if you can point out what parts of the current system are those that you are not satisfied with.

[livingforever]

I'm sorry if you know all of this, but what I want to say is, that talking about tags now is not making something out of a blue but improving, so your concept would be much easier to understand if you can point out what parts of the current system are those that you are not satisfied with.

Please check the fourth conclusion again. The current system is bad because it's basically a patchwork. If you want to make it good then a few small changes just won't do.

If what you want are algorithms, sure, no big deal. But before discussing how to implement a concept, the first requirement is that the concept is more or less final. If you just want to know what exactely is wrong with the current system then check the considerations - the current system complies with none of them (except for the fourth, sorry for missing that).

[Xela]

• Level of detail
  Tags are supposed to descripe the situation in one word, everything else is most likely not important enough to be mentioned

No, tags are supposed to describe situation in many words. I don't understand what you mean by this.

   

• Gender differentiation
  Text descriptions (and therefore customers) aren't gender neutral
• Fallbacks
  A hierarchical fallback system should be in place

Gender is obvious.

Fallbacks as a part of tagging system is absurd. This is something that should be handled with sorting logic.

Lets say you have a picture of a girl in a bunny suit that will be used during slave training for mimicry and during jobs for service/casino. You'll want different fallbacks. There are dozens of examples like this.

   

• Blocking
  If a tag without explicit fallback is not present, block the action
• Ease of use
  The tags should be intuitive and not overloaded

True, the latter might not be possible without giving away tagging freedom.

   

• Quick tagging
  All tags should fit on one editor page and should be grouped

First conclusions

• 1 & 2: Different tags for different customer types/genders are needed (at least externally)
• 2 & 3: The fallback tree is separated for each customer type
• 3 & 4: Defining the character's allowed occupations is no longer necessary - either an image with the parent tag for a job category is there or it's not
• 5 & 6: The concept is based on a bottom-up approach
• 2 & 5 & 6: The tagger hides non relevant tags or renames them based on the customer gender

Quick tagging as in removing sex tags if profile is chosen would be awesome. But that isn't easy to customize (2 + 5 + 6)

"ParentJob" is not going to fly. We will add jobs and I've already wrote what I think about hierarchy.

[/list]First approach [notes]

• Prostitute [required, hidden, own text description]
• • Sex [hidden, own text description]
  • • Vaginal [not displayed for M/M]
    • Anal
  • MakeOut [hidden, own text description]
  • • Blowjob [displayed as "Licking" for F/F]
    • Handjob [displayed as "Fingering" for F/F]
    • Titjob [not displayed for F/F and M/M]
    • Footjob
    • Grinding
• Profile [required]
• • Freetime [character is resting]
  • Exhausted [auto-rest triggered]
  • • Injured [aggressive customer triggered]
• Beach [if no image present, character won't appear on the beach]
• (Other locations) [same as above]
• Fighter [if no image present, character can't have the profession]
• • Arena
  • (Others)
• (Other jobs) [same as above]

Incomplete but it looks fine.

A few notes on the notes:
Required: At least one image with this tag is required for a character
Hidden: The tag doesn't need to be displayed in the tagger
Own text description: If the tag is used as fallback, the text description is also changed to be more general

Remaining problems
What about futas or customer groups? Differentiate between male and female interaction/groups or simply display multiple names for the same tag?

What if a slave is forced into a job with no fitting image present? Show a profile picture and a generic fail text or just don't allow the assignment?

You didn't cover who's taking the action on the pictures.

I believe that unless you want from Xela to recode the whole thing (good luck with that, I failed even when proposing a one function to read what tags are in chosen image  )

I don't remember this, what do you mean?

Please check the fourth conclusion again. The current system is bad because it's basically a patchwork. If you want to make it good then a few small changes just won't do.

If what you want are algorithms, sure, no big deal. But before discussing how to implement a concept, the first requirement is that the concept is more or less final. If you just want to know what exactely is wrong with the current system then check the considerations - the current system complies with none of them (except for the fourth, sorry for missing that).

I don't think calling the current concept "patchwork" is either fair or accurate. The concept and purpose of tagging system is to provide maximum amount of information for any given image.

We've started possible with amount of tags we have now * 1.5 or 2.

Dark/CW tagged a couple of girls and got rid of the tags we thought that we'd never use.

After that a bit of tagging again, we got rid of all tags that were far to rare and added some that could be of use for events in the future and were available for a bunch of girls.
======================================================

I am yet to see how you're planning to handle future updates to the game with your concept. Conveniently writing "OtherJobs" basically means that every time a job is added, Dark/CW would have to go though  20 - 30 thousands of images to add new hierarchies and structure. That's beyond absurd. Not mentioning that I can derive any form of heirachy imaginable and write it to a dict for quick access and checking of jobs/events/access in 1/10000 of the time it would take them to go through the images.

The power of current system is that it carries insane amount of information about the image and enables almost unlimited expansion of the game without re-tagging to include new trees. There is nothing you can do with the tree system that would get the job done half as well.

That's my take on the topic anyway. Dark/CW have tagged +/- 30 000 of images between them so these decisions are ultimately up to them.[/list]

[livingforever]

Hey there!
Alright, there seem to be a few things that seem really off to me, so I'll start with them.

I don't think calling the current concept "patchwork" is either fair or accurate. The concept and purpose of tagging system is to provide maximum amount of information for any given image.

Conveniently writing "OtherJobs" basically means that every time a job is added, Dark/CW would have to go though  20 - 30 thousands of images to add new hierarchies and structure. That's beyond absurd. Not mentioning that I can derive any form of heirachy imaginable and write it to a dict for quick access and checking of jobs/events/access in 1/10000 of the time it would take them to go through the images.

I disagree. No, I don't just disagree, I think that is absurd (or maybe beyond absurd  ). I have never in my life seen a working system that is based on infinite information instead of necessary information. It might seem convenient for you as a developer that you don't have to redo some tagging after adding a new job/location/whatever, but for the user that has to deal with what's there it's horrible and it definitely shouldn't stay this way.
Besides that, what is the advantage of tagging things that might never make it into the final game instead of tagging things after they are added?

After that a bit of tagging again, we got rid of all tags that were far to rare and added some that could be of use for events in the future and were available for a bunch of girls.

Argh, that philosophy again. You basically do lots of unnecessary work by using a top-down approach and then try to make decisions based on that work instead of just designing it bottom-up - and I really don't understand why.

I am yet to see how you're planning to handle future updates to the game with your concept.

If you are just referring to (re-)tagging effort, it doesn't make any difference wether I have to tag tons of things that aren't used yet or add additional tags after they were added. If you are referring to the general expandability of the tags, I don't see the problem.

The power of current system is that it carries insane amount of information about the image and enables almost unlimited expansion of the game without re-tagging to include new trees. There is nothing you can do with the tree system that would get the job done half as well.

Indeed. And I have absolutely no interest in designing a system that carries an insane amount of unused information. Actually, I want the opposite: A system that only carries relevant information.

No, tags are supposed to describe situation in many words. I don't understand what you mean by this.

Definitely not. Tags are keywords that are supposed to carry as much information as possible in one word. If you want to descripe a situation as detailed as possible, use a description.


So much for the general things. Now let's continue with less important stuff...

That's my take on the topic anyway. Dark/CW have tagged +/- 30 000 of images between themselves so these decisions are ultimately up to them.

I can hold against that with exactely 15658 images that I use to test different tagging approaches. If we can settle the conceptional problem I will gladly publish all of those packs.

Fallbacks as a part of tagging system is absurd. This is something that should be handled with sorting logic.

Uhm... I don't see the point. What do you mean by sorting logic? And why should that not be part of the tagging concept?

Lets say you have a picture of a girl in a bunny suit that will be used during slave training for mimicry and during jobs for service/casino. You'll want different fallbacks. There are dozens of examples like this.

And what stops you from tagging the image as both "Slave training" and "Service"?

Quick tagging as in removing sex tags if profile is chosen would be awesome. But that isn't easy to customize (2 + 5 + 6)

Doesn't sound too difficult. Click -> add the tag normally. Ctrl+Click -> remove other professions.

"ParentJob" is not going to fly.

I don't get it (propably my bad), what's "ParentJob" in this case?

You didn't cover who's taking the action on the pictures.

Indeed, and I didn't plan to. The prostitute takes the action, have you ever gone to a brothel to please someone else?

Oh my, so many quotes.
€: And no, calling the current system a patchwork wasn't fair, sorry if that was offensive. I would never have imagined that you actually have unused tags on purpose.
Have fun!

[Xela]

I disagree. No, I don't just disagree, I think that is absurd (or maybe beyond absurd  ). I have never in my life seen a working system that is based on infinite information instead of necessary information. It might seem convenient for you as a developer that you don't have to redo some tagging after adding a new job/location/whatever, but for the user that has to deal with what's there it's horrible and it definitely shouldn't stay this way.
Besides that, what is the advantage of tagging things that might never make it into the final game instead of tagging things after they are added?

It's not "infinite", did you miss the part when I wrote that tags were through through and filtered out by the only two people who'd created native content for this game on any large scale?

It has also been very clearly stated by Dark I believe that users are not forced to tag images as thoroughly as development team does.

I already stated the advantage, which is that no retagging would be required as we add new modules to the game.

Argh, that philosophy again. You basically do lots of unnecessary work by using a top-down approach and then try to make decisions based on that work instead of just designing it bottom-up - and I really don't understand why.
If you are just referring to (re-)tagging effort, it doesn't make any difference wether I have to tag tons of things that aren't used yet or add additional tags after they were added. If you are referring to the general expandability of the tags, I don't see the problem.

I need to see Dark/CW state that iterating over all images after major addons is the same as tagging them once with a larger pool of tags.

Indeed. And I have absolutely no interest in designing a system that carries an insane amount of unused information. Actually, I want the opposite: A system that only carries relevant information.

From the perspective of writing actual code, pinpoint/relevant tags are obviously far more convenient to use. This has a disadvantage that on expansion, whole thing would likely have to be tagged with new tags.

Definitely not. Tags are keywords that are supposed to carry as much information as possible in one word. If you want to descripe a situation as detailed as possible, use a description.

Yeah well, we'll never agree on this premise

So much for the general things. Now let's continue with less important stuff...
I can hold against that with exactely 15658 images that I use to test different tagging approaches. If we can settle the conceptional problem I will gladly publish all of those packs.

Feel free to share, I'd love to take a look of how different systems could be loaded and called from the game.

Uhm... I don't see the point. What do you mean by sorting logic? And why should that not be part of the tagging concept?

Because it can't be. I mean routines for sorting images and picking the best one from those available. There is no point in trying to do it with tagging because it'll have to be done with code in a lot of cases anyway.

And what stops you from tagging the image as both "Slave training" and "Service"?

Nothing, we're already doing it but if you have to specify fallbacks when calling images in the game, there is no need for doing that during the tagging.

Doesn't sound too difficult. Click -> add the tag normally. Ctrl+Click -> remove other professions.
I don't get it (propably my bad), what's "ParentJob" in this case?

If you say so.

I meant fallback/parent category.

Indeed, and I didn't plan to. The prostitute takes the action, have you ever gone to a brothel to please someone else?

LoL You tagged 15658 images and typed this... At least Dark/CW'll have a laugh

[livingforever]

It's not "infinite", did you miss the part when I wrote that tags were through through and filtered out by the only two people who'd created native content for this game on any large scale?

Mathematically speaking, a system that is based on adding as much information as possible and then filtering out what's not needed will always be countably infinite. I did not miss that part.

It has also been very clearly stated by Dark I believe that users are not forced to tag images as thoroughly as development team does.

Nobody needs to create packs in general. Is that a reason for you not to write a tagging software? No, it's not. You want people to use your systems at some point in the future, so why do you keep telling me that nobody is forced to do anything?

I already stated the advantage, which is that no retagging would be required as we add new modules to the game.

I need to see Dark/CW state that iterating over all images after major addons is the same as tagging them once with a larger pool of tags.

I'd definitely say so - after passing almost all 15k images with my systems (including several revisions) and 6299 with yours, I still feel like the 15k cost me less time. I didn't use a stopwatch though.

Because it can't be. I mean routines for sorting images and picking the best one from those available. There is no point in trying to do it with tagging because it'll have to be done with code in a lot of cases anyway.

I still don't get it (you may now call me stupid). Are we still talking about the same thing?
There is no "best" image available in my approach. Either the tag is there or it's not. If it's not, try again with the parent tag. Recurse. If the tag doesn't have a parent and no image with the tag is present, block the action.

Nothing, we're already doing it but if you have to specify fallbacks when calling images in the game, there is no need for doing that during the tagging.

See above. Every tag that is not on the first level has a parent tag. If no image with the tag is present, try the parent tag.
For the example: If no image with the "casino" tag is there, try its parent tag "service". If that still doesn't have an image, the action shouldn't be possible.
Likewise, if no image with the "mimicry training" is present, try "slave training" (or whatever the parent tag would be for that).

Parent tags can be defined with a very simple tree structure. No need to hardcode anything.

LoL You tagged 15658 images and typed this... At least Dark/CW'll have a laugh

I'm sure you don't mean it that way, but that sounds like you're trying to make fun of me. That statement was serious. Prostitutes are paid to please me, not to be pleased by me. If the image shows the second situation, it doesn't belong into the pack.

Have fun!

[Xela]

Mathematically speaking, a system that is based on adding as much information as possible and then filtering out what's needed will always be countably infinite. I did not miss that part.

Before we start multiplying infinities, we have chosen a number of tags. So practically speaking the amount is finite, lets not get carried away.

Nobody needs to create packs in general. Is that a reason for you not to write a tagging software? No, it's not. You want people to use your systems at some point in the future, so why do you keep telling me that nobody is forced to do anything?

I referenced Dark and I told you that cause it's true.

I'd definitely say so - after passing almost all 15k images with my systems (including several revisions) and 6299 with yours, I still feel like the 15k cost me less time. I didn't use a stopwatch though.

Well, I've tagged about 300 images so I rely on Dark/CW in these matters. They were in favor of the tag it once approach I believe.

I still don't get it (you may now call me stupid). Are we still talking about the same thing?
There is no "best" image available in my approach. Either the tag is there or it's not. If it's not, try again with the parent tag. Recurse. If the tag doesn't have a parent and no image with the tag is present, block the action.

I see, our concept often assumes picking best images based on location, clothing, mood (expression), maybe more. I think this is a source of confusion, we strive to create a system that would allow to pick images as precise to the requirement of an event as possible, you're trying to narrow it down to it's base.

See above. Every tag that is not on the first level has a parent tag. If no image with the tag is present, try the parent tag.
For the example: If no image with the "casino" tag is there, try its parent tag "service". If that still doesn't have an image, the action shouldn't be possible.
Likewise, if no image with the "mimicry training" is present, try "slave training" (or whatever the parent tag would be for that).

The trouble is that service tag would also include pics of a girl cooking stuff, cleaning, doing dishes. There is no way in seven hells you'd want to show that instead of a bunnygirl in a casino environment, examples like that are all over the place, can't you see that it's crap? I don't really know how else to explain that hierarchical system based on tags themselves instead ingame sorting logic is absurd. Rudi been two years at it before he introduced tagging system to us (we started out with WMlike system ourselves). We've been at it for almost an year of not longer ourselves. Noone could come up with a far better design than we have now that would be applicable. Rudi's original system is based on a very complex weight based selection that I didn't want to deal with at my level of coding skill when that system was implemented.

For the example: If no image with the "casino" tag is there, try its parent tag "service". If that still doesn't have an image, the action shouldn't be possible.
Likewise, if no image with the "mimicry training" is present, try "slave training" (or whatever the parent tag would be for that).

So we do a casino job when we have a cooking pic...

Likewise, if no image with the "mimicry training" is present, try "slave training" (or whatever the parent tag would be for that).

And so we do bunny training when we have ponygirl pic...

Parent tags can be defined with a very simple tree structure. No need to hardcode anything.

........

I'm sure you don't mean it that way, but that sounds like you're trying to make fun of me. That statement was serious. Prostitutes are paid to please me, not to be pleased by me. If the image shows the second situation, it doesn't belong into the pack.

Ofcourse I don't mean it that way. We just spent so much time coding events where a costumer girl would prefer licking prostitutes tits... or a cunt... or enjoying fucking the prostitute with a strapon and so on... came up with an extensive system to relay who's acting out on the image and wrote events and texts based on that.

Somehow you tagged 15k images and never considered that? Or suggested that we throw away all those pics? Delete the events? Get rid of the concept to simplefy the system?

I thought laughing would beat crying over it...

Look, sorry if I come out as hostile, it's definitely not the intent, especially towards someone who's offering to help developing the game but we've been over all of it with Dark and CW. I think I provide reasonable arguments from a standpoint of considerable experience and thinking the system through and you're throwing mathematical infinities as counter arguments at me...

[DarkTl]

All tags should fit on one editor page and should be grouped

Well, they should be grouped indeed, but one page thing should be optional (since tags list is xml/json based, ideally it should be customizable, like in Rudi's tagger). Tagger should not require big monitors with huge resolutions to work. I won't be able to tag at work otherwise, and I have a lot free time there.

Remaining problems
What about futas or customer groups? Differentiate between male and female interaction/groups or simply display multiple names for the same tag?

Rudi's tagger has tags like two males, one female, etc. They describe customer groups (excluding the girl, she is always there after all).
The problem with futa is lack of pack makers who willing to make futa packs 
If we'll get one, we always can expand the system. But I kinda doubt that we will in the near future.

Dark/CW tagged a couple of girls and got rid of the tags we thought that we'd never use.

After that a bit of tagging again, we got rid of all tags that were far to rare and added some that could be of use for events in the future and were available for a bunch of girls.

There still some doubtful tags exist. Since we going to retag pics (in either name or binary form) anyway after adding ST because it might require some new important tags for bdsm, we get rid of them.

If you are just referring to (re-)tagging effort, it doesn't make any difference wether I have to tag tons of things that aren't used yet or add additional tags after they were added. If you are referring to the general expandability of the tags, I don't see the problem.

The idea of regular retagging after adding every single system is not even considered. It will effectively discourage third party pack makers, and it will give us huge amounts of work without end. Tagging system should be as comprehensive as possible within reasonable limits and general game concept (ie a game that uses publicly available anime and hentai girls pictures).

I already have like 200000 untagged pics in new packs, and I stopped making them for now btw. It might be possible to retag again and again 15000 pics, but not hundreds of thousands.

I need to see Dark/CW state that iterating over all images after major addons is the same as tagging them once with a larger pool of tags.

Oh, that's simple. If I have to retag all my packs all the time, I will ragequit this dev team and join Old Huntsman's dev team, and my last words will be "see ya nerds" 

The prostitute takes the action, have you ever gone to a brothel to please someone else?

That's extremely narrow vision, sorry. I can't really give h examples right now since I don't have access to my packs all the time, but at very least the game is not about brothels and prostitutes only already.

[CherryWood]

I need to see Dark/CW state that iterating over all images after major addons is the same as tagging them once with a larger pool of tags.

I can say for myself that updating packs with tags is relatively quick, as there is usually need to look at a small part of the images (only at sex images, only at combat images...).


But the real problem of this lies within modders that create something for the game and then went inactive and obviously can't update their work. Just looking at the WM packs, how many of then doesn't support newly added jobs. So we don't want for tags to be changed after the release, and cover as many possible situation as we could now, even if they're not all used yet. Better then have girls that can't do half of the future jobs because of missing new tags I suppose.

I'm sure you don't mean it that way, but that sounds like you're trying to make fun of me. That statement was serious. Prostitutes are paid to please me, not to be pleased by me. If the image shows the second situation, it doesn't belong into the pack.

For pure whore job, this may be true, but we don't use sex pics there only. MC can have sex within private interaction (even with a warrior girl), and they're also used in classes and will be used for slave training.

But it's just a text governing tag I suppose...

[DarkTl]

Just looking at the WM packs, how many of then doesn't support newly added jobs.

Yup, good point.

[Xela]

Yup, good point.

Yeap. But it's not just that.

The tag based hierarchical system doesn't work, not even for sex images properly. We employ a very good tagging design with pinpoint precision showing, developer defined backups and customizable sorting logic on per case basis. No tree can beat that, no tree can even come close...

Otherwise, if we're talking retagging, we need a tag to exclude all sex tags other than profile (which is too general and not always applicable). That will improve tags lookup process significantly. ST tags after the concept is stable and I think that'll be it unless you guys can come up with some new tags applicable to a large number of pics. We obviously remove all tags you'd consider crap but lets not get carried away with that either. So far we stand 3 - 1 on the extensive vs pinpoint tagging concept unless I misread your posts

[DarkTl]

And I have absolutely no interest in designing a system that carries an insane amount of unused information. Actually, I want the opposite: A system that only carries relevant information.

Unused yesterday, used tomorrow. You see, it's a long term project. It seems that many people think that we are about to finish it. That's probably why they quit pretty quickly without saying a word. In fact, this is only the beginning. The game can be developed for many years, with more new modules and systems.

Btw, the main our problem is not the system. The main problem here is notorious ready-to-use, purely based on xml/json list of tags, either binary or files names outputting tagger with polished gui. I'm so tired of alpha stage taggers 

You could try to read Rudi's notes btw, both here and on Otherworld forum. He had some ideas about tags weight, they might be useful to improve the system.

[Xela]

You could try to read Rudi's notes btw, both here and on Oherworld forum. He had some ideas about tags weight, they might be useful to improve the system.

I always thought those were insane

But with some practice... it may work. Rudi definitely thought so and he spent more time thinking that through than all of us combined.

[livingforever]

Hey everyone!
Alright guys, I think we can stop here. You convinced me that I won't be able to convince you.

Quick note to Xela: I still have no idea why you think that a hierarchical system doesn't work - you see problems where there are none. If working in a casino is part of the maid job, the maid outfit can be used just as well. And if the tag changes in order to use a fallback, so can the text description.

But that's not important now. I'll try to make my honest opinion short:
You guys spent a huge amount of effort and unnecessary time on a system that is fundamentally wrong. I mentioned it earlier, I've never seen a well working system built the way you do it before, I'm curious how you'll see this in a year or two.
Anyway, I can understand why you don't want to go back now, after all that effort.

As it stands now, I can promise you that you will (and propably already did) lose a lot of potential pack creators, simply because your system is so "extensive" that nobody wants to deal with it (except for very dedicated people).
As for me, I see it as a challenge. You guys made cleaning up the current concept a lot more difficult.
Also, I wish you lots of fun while doing exactely what you wanted to avoid with your system: Retagging. It propably won't be the last time.

Ok, that last line is very cynical, sorry  .
Have fun!