Todd Mitchell wrote: > I think that we are getting somewhere with this. Two things I have been > thinking. > > I would suggest using @ as the delimiter instead of something like --#-- or > another invention as this is consistant with the message field for npc > speaking and I am a fan of consistancy. So you would see: Well, what the seperator is isn't really important. Just as long as it is something other than a newline. > I am not sure that assigning value by number is better than simply assigning > value by position since it will not be consistant across arches (one person > my set resistance info at @3 another at @5 for example.) I would argue that > simply weighting the data according to their position would be alright since > more interesting creatures would have more lore lines attributed to them. > Another option would be to put the weight value (as a percent?) after the @ > so you would have: > > lore > @60The llama is a quadreped. > @30Llamas are not frogs > @9Llamas sometimes lay golden eggs. > @1Llamas explode instantly when you say 'Ni'. > endlore This might be more interested, combined with ranking them. Thus you could do something like have useful information show up even in low level books, but more likely to show up in higher level books. I personally would remove the idea of a percentage, and just have it a weighting. If the person decides to have the values total up to 100, that is fine. If someone instead has them total to 23, that also works. It just something with a ranking of 3 would be 3 times more likely to show up than something with a ranking of 1. Your point about people using different difficulty for ranking is valid. However, the converse is that maybe you have something you want to have 20 different lore entries for, but maybe the info should be basic. > As for the map lore - I do agree that a message file should be used to house > information on quests and landmarks and other mappish information, (I didn't > think to load this when the map is loaded for example since the lore should > be available before the map is used presumably) but I would like to suggest > a lore field in maps anyway and script that can be manually run which will > collect this info and feed it into this message file. For a standard map > set this will only be required to be generated in the same way as the arches > are collected (and with the same frequency as the arches are collected in > CVS), and the messages file will ship with the server the same way the > collected arches do now. It is simply a way to encourage the generation of > lore during map design, and a way to modularize the data so that servers > with custom maps do not have to manually add or remove the data. You've > probably guessed by now I'm big on the seperation of server and design. Given the complexity of doing this (extending the map header, writing a script to collect it, etc), I'd rather just have people put it in the messages file by hand. _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel