Hey everyone,

I finished writinghttp://www.creationkit.com/Creating_Multithreaded_Skyrim_Mods, showing the method I used recently to successfully take advantage of multithreading series of (largely similar) tasks in Papyrus in order to get the results faster (http://www.reddit.com/r/skyrimmods/comments/2sfo17/the_need_for_speed_frostfall_is_about_to_get_fast/, in my own tests).

Please give it a skim and let me know what you think. I plan to finish the tutorial example into a working one soon, so it can be downloaded and inspected. Hope it helps!

Awesome! I saw your Reddit thread about multi-threading in Papyrus a day or two ago and I've been looking forward to reading the finished tutorial. I need to have a go at implementing this at some point even if it is only to try it out.

I think the tutorial is well written and clear. There are enough details about the concept without going overboard.

Nicely done!

Some minor feedback:

• PlaceAtMe shouldn't hang. A 'frozen' OnInit() event will make that particular script unusable (no one will be able to call functions on it until OnInit is done), but the object should still exist in the world and PlaceAtMe (should) return.
• If you flag your 'thread' base class as "Hidden" it won't show up in the list of scripts to attach to the quest, helping reduce the chance of mistakes Just add the word "Hidden" after the "extends Quest" bit. If you look at fragment scripts, they do this same trick to avoid showing up in the script list when you attach scripts to things.
• GetThreadID can't be global - globals can't access variables on the containing script.
• Casting won't work outside a function, so I'm assuming your "GuardPlacementQuest as GuardPlacementThread01" code is actually in an OnInit()?
• You may want to make a note about shared resources and how that can hinder threaded systems like this. For example, if your quard placement calculation function messes with some shared objects between all threads (like, say, the player), then the threads will "sync up" on those calls and take their turn, reducing the speed of the script.

As an extension of all the work you've already done - perhaps you could also look into providing a version of this system that uses callbacks instead of futures? That could be done via a common base class with a "OnFinished(x result)" function that the children override and the threads call when they've calculated the result.