Thanks for the update, was wondering how things were progressing. Two points to consider;
1) not entirely sure why you've set the script up so it's calculating smoothing instead of just reading vertex split data in the file and 'format parsing' that (that's the only significant difference between Blender ASE and Max ASE where smoothing is concerned), much less costly and much quicker to do.
2) related to the above, I'm not sure why you've chosen to focus on angle based smoothing (to be set as default later?), it's practically useless for game content because
it's arbitrary in implementation; the only reason people use it is because it's easier to do and more broadly, because they don't understand what smoothing is or how to properly set it up on a mesh. Both reasons result in incorrectly mesh smoothed models and encourage lazy/bad technique.
So, I'd suggest/recommend ditching the use of angle based smoothing and/or switching focus so it's an option rather than a default. I'd also find a way to parse scene data rather than have the script pull in a file and then do all the calculations (which it appears the script is doing right now?) - as an aside here, you may not know this but Goofos' very first ASE scripts for Blender did exactly what you're doing now with disastrous results, some files took tens of minutes, and very large files (terrains), hours, to output instead of seconds, it wasn't until he switched to simply parsing scene data that vast improvements were made. All you need to do is make sure the users applies any modifiers or force that on export.
Sometimes in trying to make thing easy one ends up making things more difficult
Other than the above, excellent work!
[
EDIT]I just read your smoothing tutorial and realised you're trying to replicate the limited mechanism that Max uses for it's smoothing systems, that's not going to work with Blender because there are two general problems with this approach.
1) as you noted in the tute, Max is limited to 32 groups so you have to be 'creative' with your application on more complex models (terrain again being a classic example) otherwise in trying to replicate Max output exactly, you're going to 'mush' (compress) groups together... that again means an arbitrary distribution based on what the script thinks is best, not the artist (the script doesn't know what the object is). If ASE is hard limited to using actual groups rather then just maintaining vertex splits (see below), then it's probably a better approach to output a warning to the user saying an object has more than the recommended groups and should be optimised better or some such... you've always got to keep control in the hands of the artist.
2) a smooth group in a game engine is ultimately nothing more than an area defined by a vertex split, so all you need to do is find a way to maintain that at output (easier sad than done I know); using Max as a reference is going to be problematic because it formats the same vertex split data as (face) 'groups', if those don't exist UDK et-al merges the very same vert splits that would otherwise be 'valid' groups were it not for their (incorrect) formatting.
