Lalo Martins wrote: > Scorn ranks and Kurte scholarship are forces. Army membership > is not really recorded, you just have to know a password (which > is arguably a bug, since you can get the password from other > players or other, less honest ways). Just as a note, there are probably lots of other cases where that is the case (password which is player knowledge). In some cases, that makes sense (the password to open the scorn gate is literally a password). Membership is tricky however. One could make the case that it potentially makes more sense in some cases to get an actual token showing membership (like a police officer might have a badge). Something like the nobility of scorn, and perhaps others, are maybe more generic. The nobility of scorn can be seen as something that is public knowledge, eg, the guards of scorn know who are knights, lords, etc, and act accordingly, and thus don't need visual clues (sashes, pendants, etc). I realize that isn't really the point, just some random thoughts I'm having. It just sort of means that there are a few different categories we could put such memberships into: 1) membership is a public thing, and everyone (npc) dealing with the character would know of the appropriate membership. Eg, scorn knight quests. Membership checking in guilds, etc. 2) membership is private and not globally known. A case I could think would be secret societies - there is no way a secret society could inform all its members that XYZ is a new member. In these cases, passwords or tokens (sashes, pendants, etc) could be the way to show membership. The use of tokens also more or less restricts it to people do the quest properly (or getting someone to give that token) 3) membership really is password, eg, getting into a bar, opening the gate, etc. On to your points below: > > 1. Introduce a new object type, tentatively named "title". No reason to make a new object type - just make a subtype for the FORCE object - after all, the force object should still meet all the needs - you just want to note that some of them perhaps have special meaning. Making it a subtype should mean fewer code changes. > > 2. You see all your "titles" when you click on yourself. > (Actually you see the "title" field of each of them) This requires that the titles be set to meaningful (printable/english values). I don't know what the case is right now, but you don't want it to be something like 'scorn_knight' and print that to the players. Note that there are currently commands that show various player details (stats, skills, spells) - it probably makes more sense to put it in there or make a new command that shows that information. > 3. Titles are grouped by "race" and ranked by "value" [1]. If > you get a title with the same "race" of another one you have, > you only keep the one with the highest "value". Exception: if > both have "value" 0, you keep the newest one. (That means in > order to *decrease* rank on purpose, you have to first get rid > of the old object explicitly.) Seems reasonable. > > 4. When other players click on you, they see all your titles > that are not "invisible" [2], so you can look at someone and see > that (s)he is a Duke of Scorn. The invisible field already has to be set just so these forces don't show up in the players inventory, so some other field/flag would need to be found, but that shouldn't be too hard. Following my discussion above, I'd think only case #1 should generally be visibile, eg, those things that are of general knowledge. Actually, an interesting extension would cases where you could only see membership if you have a title of the same race. Eg, members of the guild of the iron fist could see/know the status of other members of the guild. But they would have no clue about members, or even who are members, of the red lantern or whatever. _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel