Hah, was wondering if that was you while I was reading that! Funny
Yeah, I agree that it would be best if we could do it all in SoF.cpp, but I think it would be tricky in some cases like this where stuff is being hard coded and not put into any sort of structure. Unless maybe we could recreate the same commands with alternate settings in SoF.cpp, I dunno any other way to do it. I was thinking about if it might be possible to set encodes for the special/formatted/common or whatever messages packets that would look for a string that looked like an item link and then add the required 5 0s in there. But, that would be quite a hack IMO, and might cause more issues than it would be worth. One solution I was thinking of would be to make alternate commands just for SoF (#sofitemsearch, #sofpeekinv, etc), but that would be much less than ideal imo. The only other thing I could think of would be to create a rule that would let admins set if they wanted to use SoF settings for stuff like command output and anything else that might need to be changed. Then, we could have a simple rule check, but again that would be less than ideal as well.
I don't think there are many things that would have to be changed outside of the SoF.cpp that would effect the other clients. For most things that are hard coded, I have just been able to just create new opcodes and handling that doesn't effect Titanium users. In this case, that isn't really an option as far as I can think of unfortunately.
Oh, and a client version check function would be nice to have handy for certain situations. I would really like to have a way for a porting NPC to check if the client is SoF or not so it doesn't port Titanium users to zones they don't have. I am sure there are plenty of other times that would come in handy as well if we are going to have 2 compatible and fully functional clients (not counting 6.2).