As you pointed out, there hasn't been a big demand for this platform. So there's no one to share bones files with for that platform, and your Debian user would be reduced to hopefully uploading bones and sobbing piteously.
That doesn't mean I'm not interested in the underlying problem though. As you correctly say, the existing code is geared to expect four 32-bit values for version info. To be honest, this was due to a sheer lack of foresight on my part. Initially it was intended to be for Windows NH only, and other platforms didn't come into consideration until later. That said, it's a bit much to assume that the DevTeam will retain this method of versioning bones files indefinitely. Even if they do, there are other supported variants (such as Slashem) which may well diverge, and (currently unsupported) roguelikes who will have their own weird and wacky versioning system. So certainly, in the future I want a nice backward compatible method of taking an arbitrary amount of version information and getting a unique identifier from it. The easiest way that comes to mind is to build up a string of the version numbers and then take an MD5 of it. That one's going on my 'To do' list, but I don't expect to have much time free to do it in the near future, real life being what it is. I also don't think it's very urgent, rather the kind of thing that's good to have out of the way in case the DevTeam decide to change their versioning system overnight. They don't consult with mere mortals like me, y'know :) So the underlying problem will be fixed once I get some free time. Please let me know if you hear about this issue from any other users - once there's a bit of demand from 64-bit NH users, it'll be worth adding support for them to the server. Cheers, -- A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
