> This should be moduler I suppose. Also, it should be mentioned that any extra information about an item could in theory break alot of puzzles. I suspect this situation is somewhat similar to that of the implementation of PR. Alot of things may or may not break, but it shouldn't take very long to iron out the major bugs then focus in on the specifics. > I don't think it will actually break any puzzles. It may just make it very apparant that the items you picked up are special items because they got sorted in a place that you would not expect them to be. But changing the client_type in the map should be the only necessary change. Note of course even with client_type, player can still gain some information. If that key is disguised to look like a helm but in fact is still a key, if a player tries to put the item on or otherwise use it as a helm, he will quickly find out it is not a helm. > > I had originally thought of using the objects current type as client_type if > > not set. The problem is that the type fields are not in any order (I would > > prefer all my armor things to be together for example). I had thought about > > making a map table, but then figured it was just as simple to write a perl > > script that contains that information to update all the arc files. > > I suppose this is where a major problem lies. I think garbled (Tim) suggest a good idea for classifying such things, I will let him reiterate it. Of course for the situation of item mapping for the client, more than just a type is really needed, it where is it on the body? An axe doesn't actually imply where it should be placed on the body, and for things like multiple weapons, clever things like more than 2 rings for fireborn etc that sort of information would become invalueble. As per the other mail, this is really two discussions. Currently, the main thing that type is used for is sorting in the actual inventory window. Note that client_type would probably be enough information in most cases to know where it goes on the body. Right now of course that information is just contained in the type field - Presuming that the client_type is accurate and that it actually has a finer resolution than current type, you could in fact use that information. > Err why not just update the 'name_plural' value?? If you are gonna store that info in the .arc file, surely it would be a simple matter to update it for the map specific items, grep? True - that is probably the best solution, and if something isn't done right in a map, it will be quickly discovered.