I tried merging my latest changes in, and I may have mucked something up. Sorry GP, but can you double check what I did. It looks like I merged the master changes back into my branch, but that's not what I meant to do.

Anyway, I don't have any unchecked in changes at this point. I'll wait until the sourcetree is resolved before pulling from master again.

However, it seems to me the problem is caused by genhtml.py at line 86, where the called function expects the region instance instead of the region name. I've fixed this by modifying the implementation of the get_origin_name function to accept a region name and load the region object, as you did in the other functions in config.py.
I've committed the modification and pushed it to Code-Refactor (pull from there, master is now a couple of commits behind).

# weapon_frequency_by_region, weapon_frequency_by_origin to be loaded from config-specific file, same for the actual stats
# weapon_by_class is fixed or more likely obtained from class_obj
def weapon_selector(cclass, region, origin):
# Combine frequencies by region and origin, e.g., take lower or very rare if it appears only in one of the two
weapon_selection = combine_freq(weapon_frequency_by_region[region], weapon_frequency_by_origin[origin])
# Remove disallowed weapons by class, using the base weapon to reduce clutter (i.e., matara is allowed to classes that can use the bastard sword)
weapon_selection = { weapon : weapon_selection[weapon] if base_weapon[weapon] in weapon_by_class[cclass] }
# Usual selector
return join([ [w]*weapon_selection[w] for w in weapon_selection ], [])
weapon=choice(weapon_selector(cclass, region, origin)

Since it was already refactored, I tried a similar approach with the Immortals. For now, it is quite partial, and the old format is still supported.
However, if a dictionary is used in the origin class instead of a list, the selection will be driven by the dictionary (removing all elements that are not found in the base_set, of course). This does not take into account religions from the region class, though, so I'll work on that next (hopefully tomorrow).
This modification has been pushed in the master branch, so the Code-Refactor is now behind by this commit.

I didn't have much of a chance to work on anything this weekend... we had one of the hottest heat waves in history here - I didn't even turn on the computer for fear it would melt .

I'll catch up and comment soon. I think at this point I'm ready to merge back in with the main line. I haven't made any additional changes since my last update, so I should be able to just work off of main now.

I like where you're going with the weapons. Let me give it a think through.

I'm probably going to look at the origin coding a bit more as well. The one issue that I ran into was the multi-ethnic origins. For example, most origins (as they are currently set up) work pretty well if they are mapping a single Race-Culture combination. The Lupin origins are a good example of this. However the multi-ethinic origins (think Eusdrian for example which can be applied to Elf, and Halfling - each of which have their own distinct racial class) prove a little bit more problematic. Not sure how I want to tackle that yet, but there is definitely some more thought required.

I'm also probably going to take a look at adding some kind of clan structure for specific origins. That way we can set up clans for Alfheim (and other elven realms), Rockhome (and other dwarven realms), probably even use the same mechanism for humanoid hordes, etc... At some point I'd like to tie that back into the name generation code.

For clans, at the moment I only set up Norwold Dwarves with a different set of clan names.

For Eusdria, I see there is some problem... probably race/class mixes that are not allowed. We need to filter out the disallowed classes, much like I did for the immortals disallowed by alignment or region.

I just pushed a proposed solution for the Eusdrian problem. It uses the class list in race_obj as a filter, but we can go for a different option, using the combine_freq function instead (see its use in immortals.py)

I've implemented a full new version of weapon selection, based on frequencies for both class and origin.
This led to a major simplification of the weapon selection code, which is good.
I've also added common_weapons fields to all origins, as well as overhauling the by_class structure in weapons.py
There are also other considerations that might apply, such as how to create a way to connect weapons and skills (e.g., a lance master should also have riding skill...), but I think for now it will remain as is, and further customization should be implemented much like the special Ethengar classes (which have their own weapon and skill selection).

Also... I think I broke the Eusdria fix you put in a while back. I didn't quite understand what you were doing until just looking back over it now. Let me fix it. I want to play around with a few different ideas. (I'll probably have to muck around a bit more in config.py) I want to get a solution that will work for both the Eusdria (which may need to filter classes by race) and also the Moadreg (which adds a new dwarven class - Dwarf Wizard). I think the solution might be to make the origin class a little more self descriptive with regard to what race/class combinations it will accept.