Page 1 of 1

Race, skill, power objects

Posted: 13 Aug 2011, 20:11
by lgromanowski
amos wrote: I'm nearly* done with the window for choosing the race and wanted to add some content to it by filling in with the defined races, skills and powers.
Just wondering how you intend to access these data? Now the imported data is in the ESM store, should I let the window class access the store directly or do you intend to provide some wrappers for this data, e.g. a separate class for Race, Skill etc. which either copies or references the store.

Or should I let the race window not now about the ESM store or any wrapper classes and instead let the caller pass the necessary data?

I already started on some classes for race and skill, so if you want I could continue that work.

* Lacks tooltip and 3d head
Zini wrote: Edit: looked at the code again. What I wrote previously was nonsense.

Here is how we really should do it. The GUI system can pull data from the ESM store for display purpose, but nothing more. So it would basically be the GMSTs. All the runtime data is outside of the scope of the ESM store anyway.

I suggest, that all the other stuff (classes, races, skills) is inserted into the GUI from the mwmechanics sub-system. Since this is part of the business logic its rather part of my task than of yours.

Edit2: Also, if you have something semi-workable already, maybe you could push it to your repository on github so that we can have a look at it too.
amos wrote: Sure, I'll push it a bit later today.
amos wrote: I pushed my changes to a new branch "gui-windows" on my repo:
http://github.com/am0s/openmw/commits/gui-windows

The windows is currently shown when pressing "i" as that was the fastest to work on it.
Zini wrote: Looks pretty good. Here my comments:

- Opening character creation windows is already implemented. You have already found the WindowManager::updateVisible function. But instead of inserting it into the GM_Inventory section, add a new section for GM_Name, GM_Race and so on. These windows can be opened from the console via the usual script instructions: EnableNameMenu, EnableRaceMenu and so on.

- The hardcoded values obviously need to go.

- It would be helpful, if you could implement the windows in the right order (i.e. the order in which they are shown to the player). The name window comes before the race window.

- Just noticed that these windows have back buttons. Please make sure, that these buttons automatically open the previous window.

- I thought about how to handle the race stuff again. Maybe my previous suggestion wasn't so good. The window is displaying quite a bit of information and it would get rather complex if we route that all through mwmechanics. You can as well read out the race data directly from the ESM store object. But again only for displaying purpose. I will do the actual stats manipulation in mwmechanics, based on the callbacks it receives from your window classes. I don't think we need any new classes to represent races, classes, skills and such. Just loop through the ESM store lists and display the data.

- Any chance you can lose that tab and use spaces (preferably 4) instead? We are not very strict about indenting, but AFAIK no one is currently using tabs and the last thing we need is even more variety.

- There is little point in prefixing file names in mwgui with mw_. Even the mw_layout name is mostly an accident resulting from an earlier design decision, that was later reversed. I wouldn't be sad to see it go entirely.

Edit: spelling
Zini wrote: Also, you might want to synchronize with my newchar branch occasionally. I just pushed the interface for the character creation. You can get the MechanicsManager object via the Environment object, that is passed to the WindowManager at construction.
Zini wrote: A few more things to consider.

- When the okay button is clicked and the next window was already opened at least once, this window should automatically be re-opened.

- When going back and forth with the back and okay buttons, windows that have not been opened (via a script instruction) yet, should be skipped.
amos wrote:
Zini wrote:- Opening character creation windows is already implemented. You have already found the WindowManager::updateVisible function. But instead of inserting it into the GM_Inventory section, add a new section for GM_Name, GM_Race and so on. These windows can be opened from the console via the usual script instructions: EnableNameMenu, EnableRaceMenu and so on.
Yeah, on my list already.
- It would be helpful, if you could implement the windows in the right order (i.e. the order in which they are shown to the player). The name window comes before the race window.
True, i forgot about that one. Is there a need to have a reusable input dialog like the name dialog, just seem to remember that mods could ask for input. Or maybe i'm confusing it with Oblivion or Fallout 3.
Anyway I think I'll design it that way, to not have it tied to the specific name input.

We'll also need the info boxes which has text and an ok button.
- Just noticed that these windows have back buttons. Please make sure, that these buttons automatically open the previous window.
I plan to use MyGUI delegates (ie. events) for them, then create a top-level class to manage the entire character generation process.
- I thought about how to handle the race stuff again. Maybe my previous suggestion wasn't so good. The window is displaying quite a bit of information and it would get rather complex if we route that all through mwmechanics. You can as well read out the race data directly from the ESM store object. But again only for displaying purpose. I will do the actual stats manipulation in mwmechanics, based on the callbacks it receives from your window classes. I don't think we need any new classes to represent races, classes, skills and such. Just loop through the ESM store lists and display the data.
Ok, i'll make use of the store directly.
Just thinking about the structs in the store, right now they represent the data in the esm, would it be an idea to improve them to actually become better C++ classes at some point. I don't mean a complete rewrite but for instance to use enums etc.
For instance the RADTstruct could be placed on the stack and then copied to the specific fields.
- Any chance you can lose that tab and use spaces (preferably 4) instead? We are not very strict about indenting, but AFAIK no one is currently using tabs and the last thing we need is even more variety.
Yup, I'll fix that. Already changed my editor settings.
- There is little point in prefixing file names in mwgui with mw_. Even the mw_layout name is mostly an accident resulting from an earlier design decision, that was later reversed. I wouldn't be sad to see it go entirely.
I'll go over and cleanup when I get the dialog close to completion.
- When the okay button is clicked and the next window was already opened at least once, this window should automatically be re-opened.

- When going back and forth with the back and okay buttons, windows that have not been opened (via a script instruction) yet, should be skipped.
I'll use character generation manager for this as mentioned above.
Zini wrote:
Just thinking about the structs in the store, right now they represent the data in the esm, would it be an idea to improve them to actually become better C++ classes at some point. I don't mean a complete rewrite but for instance to use enums etc.
Actually a complete rewrite is exactly what is needed. But that would set us back several months, because it would affect almost every single part of OpenMW. Maybe this can be done for OpenMW 2.0 or even OpenMW 3.0, but now is not the time to get into it. We want to get to OpenMW 1.0 as quickly as possible.
Since we might be going to scrap the whole thing at some point in the future, I see little sense in trying to improve it now.
True, i forgot about that one. Is there a need to have a reusable input dialog like the name dialog, just seem to remember that mods could ask for input.
I don't think there is such an input dialogue in MW. But more generic and flexible is always welcome, as long as it doesn't create a lot of additional workload that delays OpenMW 1.0 further.
amos wrote: I agree, getting a working version is high priority.
amos wrote: I've done more work on the dialogs, implemented the name input dialog and place both name and race dialog to be shown by the script commands.
Race dialog now also fills in information from the ESM store.

Plus lots of other smaller fixes.
Zini wrote: Looks mostly good. Will pull and test either later today or tomorrow. However the changes to loadskill are wrong. You are supposed to fetch these names from the GMST settings instead.

Edit: Okay, further problems:

1. At least the name window does not get the input focus when opened. Unles I explicitly click on the window, the keyboard input is instead going to the console, which is already closed at this point.

2. In RaceDialog::updateSkills you are searching by the display name of the race instead of the internal ID. This won't work.

Edit2: And one more:

3. OpenMW does not automatically switch into GUI mode, when the name window is opened (via script). You can test this by running OpenMW with the --start option set to the very first cell (Imperial Prisonship or something).

Edit3: And another one:

4. You are using the string literal "Name" as label in the name dialogue. But I am pretty sure, that there is a GMST setting for this. This probably will affect parts of the race window implementation, too.
Zini wrote: More testing:

5. After clicking on the OK button in the name dialogue, OpenMW does not leave the GUI mode.

6. Pressing the return key in the name dialogue should have the same effect as clicking on OK.

7. There are several warnings in layout and race. Could you silence them please?


I have started the mwmechanics-side of the character creation implementation and I noticed, that the stats window is still very incomplete. It would be useful, if you could enhance it at least to the point, that it can show the skills. That way we will be able to actually see the effect of our combined work on the created character. We need:

a.) a way of setting the level of a skill (similar to how attributes are handled; you may want to look at the interface and the implementation)

b.) reorder them (multiple times) into the three categories (major, minor, misc). I suggest an interface like this:

Code: Select all

void configureSkills (const std::set<int>& major, const std::set<int>& minor, const std::set<int>& misc);
amos wrote:
Zini wrote:Looks mostly good. Will pull and test either later today or tomorrow. However the changes to loadskill are wrong. You are supposed to fetch these names from the GMST settings instead.
Ok, fixed.
Zini wrote:Edit: Okay, further problems:

1. At least the name window does not get the input focus when opened. Unles I explicitly click on the window, the keyboard input is instead going to the console, which is already closed at this point.
Fixed now.
Zini wrote:2. In RaceDialog::updateSkills you are searching by the display name of the race instead of the internal ID. This won't work.
I was going to fix that but forgot about that one the way, fixed now.
Zini wrote:Edit2: And one more:

3. OpenMW does not automatically switch into GUI mode, when the name window is opened (via script). You can test this by running OpenMW with the --start option set to the very first cell (Imperial Prisonship or something).
The problem was the script system called WindowManager::setMode() which only sets up the windows and does not notify the input manager. I did a quick for it, later on the mode management should probably be placed in a more central location.
Zini wrote:Edit3: And another one:

4. You are using the string literal "Name" as label in the name dialogue. But I am pretty sure, that there is a GMST setting for this. This probably will affect parts of the race window implementation, too.
Ok, didn't know you could override that. Found the ID sName which I confirmed with a custom mod. Fixed now.
Zini wrote:More testing:

5. After clicking on the OK button in the name dialogue, OpenMW does not leave the GUI mode.
Same problem as with the script commands, fixed now.
Zini wrote:6. Pressing the return key in the name dialogue should have the same effect as clicking on OK.
I actually had this implemented but it crashed, it was a problem when the dialog was deleted. I've fixed the issue now.
Zini wrote:7. There are several warnings in layout and race. Could you silence them please?
Done, there's plenty of other warnings in files I haven't touched though.

Zini wrote:I have started the mwmechanics-side of the character creation implementation and I noticed, that the stats window is still very incomplete. It would be useful, if you could enhance it at least to the point, that it can show the skills. That way we will be able to actually see the effect of our combined work on the created character. We need:

a.) a way of setting the level of a skill (similar to how attributes are handled; you may want to look at the interface and the implementation)

b.) reorder them (multiple times) into the three categories (major, minor, misc). I suggest an interface like this:
I'll se what I can do.
The stats window shares lot of functionality with the review window, at some point they should probably use similar code, maybe as custom widgets.
Zini wrote: Looks good. I had to make a minor adjustment to make your code compile on gcc (now pushed to my fork).

On the mwmechanics side the attribute handling is already in place. It is possible now to try out different classes to see how the stats are changing. If we continue at this pace we will have the character creation sorted out pretty soon.
amos wrote: I made a page for the various windows/dialogs so that I can keep track of what needs to be done.
http://openmw.org/wiki/index.php?title=GUI_(Status)

Edit: Correct link: http://openmw.org/wiki/index.php?title=GUI_(Status)
Zini wrote: Good idea (the link in your post is broken though). From what I see you have most of the GUI elements covered. Still missing in your list are:

- non-window HUD elements (spell-effect icons and such)
- minimizing of windows (at least the map window can work either as a full map window or as a small map icon at the bottom right corner of the screen)
- some skill-specific windows (Alchemy?)
- main menu, load/save dialogue, options menus, ...

Also I would change the message box section, because there are two different kinds of message boxes. One with button and one without (they probably won't share and implementation).
amos wrote: Thanks, I'll add them later today. Just needed a starting point, I had most of these notes locally and thought it better to put them on the wiki.

A couple more I can think of:
- Create spells
- Enchanting
- Hotkey window
amos wrote:
Zini wrote:Also I would change the message box section, because there are two different kinds of message boxes. One with button and one without (they probably won't share and implementation).
Do you have an example of these boxes?
Is it the ones where the user has to choose between one of several text boxes?


Btw, the stat window is now updated, you can set major, minor and misc skills as you suggested. In addition you can set the factions, birth sign, reputation and bounty.
There's no scrolling yet, I'll add that later on, for now just resize the window.

Code: Select all

      void configureSkills (const std::set<int>& major, const std::set<int>& minor, const std::set<int>& misc);
      void configureFactions (const std::vector<std::string>& factions);
      void configureBirthSign (const std::string &signId);
      void setReputation (int reputation);
      void setBounty (int bounty);
      void updateSkillArea();
Call updateSkillArea() after all fields are set.

Btw, is std::set the correct container for skills, doesn't the order of skills in each group matter?

Now onto the remaining character creation dialogs :)
Zini wrote: MessageBoxes:

1. You have the boxes in the middle of the screen (one or more buttons)

2. You have the boxes at the bottom of the screen (no buttons); fixed-size; up to 3; timed, based on the amount of text and a GMST setting.

Skill std::set: I didn't thought about that, but you are probably right (order within a group doesn't matter, but to match the MW implementation we probably should keep it). Maybe a vector would be better. Another thought: do we need the misc container at all? Major and minor should be enough to determine the skill categories.

updateSkillArea: Can we remove this function? Skills and other stats are usually not changed in batches (except at the character creation), so changes should be applied instantly.

configureFactions: IIRC factions have a rank (probably only shown in the tooltip). A simple vector of strings won't do here.

General interface: Your additions to the window manager are a bit inconsistent with the existing interface. Look at the setValue functions please. The idea behind it was to avoid a fat window manager interface (since the window manager acts as facade for all GUI elements). The GUI system should be largely agnostic towards game mechanics. It should receive label-value pairs, that are displayed in a layout-defined manner.

I don't see a function for setting skill values. This should be routed through a new setValue function with the following signature:

setValue (const std::string& id, const MWMechanics::Stat<float>& value)

The fraction part of value is the progress.
amos wrote:
Zini wrote:Skill std::set: I didn't thought about that, but you are probably right (order within a group doesn't matter, but to match the MW implementation we probably should keep it). Maybe a vector would be better. Another thought: do we need the misc container at all? Major and minor should be enough to determine the skill categories.
Might not need the misc category, allthough the benefit of having it set from the mechanicsmanager is that the stat window does not need to know about how many skills there are. But I can remove it for now.
Zini wrote:updateSkillArea: Can we remove this function? Skills and other stats are usually not changed in batches (except at the character creation), so changes should be applied instantly.
Yeah, I plan on getting rid of that. It was a temporary measure to avoid having to setup the widgets multiple times.
Zini wrote:configureFactions: IIRC factions have a rank (probably only shown in the tooltip). A simple vector of strings won't do here.
Ok, will add.
Zini wrote:General interface: Your additions to the window manager are a bit inconsistent with the existing interface. Look at the setValue functions please. The idea behind it was to avoid a fat window manager interface (since the window manager acts as facade for all GUI elements). The GUI system should be largely agnostic towards game mechanics. It should receive label-value pairs, that are displayed in a layout-defined manner.
I'm not sure I really agree with this design. For instance having setValue("name", playerName) vs setPlayerName(playerName) is not really a huge benefit, you get less functions in the API but it it less understandable how to use it.
Also the HBar, MBar, FBar, and AttributeVal* labels are not really helpful, you are directly targeting a gui element rather than setting a specific game value. Why not just have setAttribute(id, Stat<int> &value) (e.g. setAttribute(Agility, agilityStat); ), where id is either an enum or an attribute ID, and setHealth(), setMagicka, setSkill() etc.
There won't be that many functions so I don't see it as a fat interface.

As I see it either we send all values through appropriately named functions, or we send a Player object of some kind (pointer or copy).
Just imagine the inventory window, how do you expect to fill that in with this approach. This window is just a specialization of a loot window, the listing of items is the same, it would be much better to actually get that
information from a "bag"/"container" object of some kind.

I just feel that mixing GUI specifics into the mechanics manager is not the right approach, let's keep GUI separate from game mechanics and use a player API to pass appropriate values.

But if you really feel strongly for this design I will convert it, and then we can discuss it again post 1.0.
Zini wrote:I don't see a function for setting skill values. This should be routed through a new setValue function with the following signature:
Ok, will fix.
Zini wrote:
Also the HBar, MBar, FBar, and AttributeVal* labels are not really helpful, you are directly targeting a gui element rather than setting a specific game value.
Actually, no. These labels are not directly tied to GUI elements. They are just labels for the specific stat.
I just feel that mixing GUI specifics into the mechanics manager is not the right approach, let's keep GUI separate from game mechanics
That is exactly what I try to promote with the setValue functions.

Anyway, I won't try to insist on this design. If you prefer your existing interface, you can keep it as well.
amos wrote: I've updated the stat window, you can now set the skill values with setValue(id, const Stat<float> &stat);
The ID is "Skill" followed by the name of the skill as in the enum, e.g "SkillMediumArmor".

Also:
* Factions are now set as a pair of string/int values, where the int is the faction rank (setFaction).
* Removed the need to send misc skills.
* Birth sign is now set with setBirthSign (was configureBirthSign).
* There is now a scroller in the window, there might be some glitches when scrolling/resizing but it should be sufficient for now.
Zini wrote: Just a note: If you haven't changed it by now, you can keep the update function for the time being. I just looked at my code again and it seems we are doing GUI updates in batches at the moment. I would like to get away from it eventually, because it is not very efficient. But right now it doesn't have a high priority for me.
amos wrote: Ok, I'll keep it for now. I'm thinking of finding a smarter way to update this, for instance having it called before (or after) a frame. That way any gui updates that are required will be done in one go before it has to be displayed.

I just finished the class and birth sign dialogs. For class it is only the dialog for picking pre-made classes, I will have do the other two when the review dialog is done.

The spell text for the birth sign dialog also needs to be improved. I first need to make a list describing all the builtin spell effects (GMST id, applicable fields etc.).
amos wrote: The dialog for creating a custom class is almost finished (skipped review for now), just needs to add the description edit field dialog.

The question is how this should tie in with the mechanicsmanager, should it report all fields it has chosen and let mechanics deal with the rest.
Should we create a new class for the custom class? I think we have to as we are referencing classes with a string ID.
Zini wrote: Look at the mwmechanics interface, please. There is already a function for choosing a custom class. Just create a ESM::Class instance and pass it along.
Zini wrote: Just did another mwmechanics push. Basic character creation is almost complete now. The only major feature missing is the handling of magic effects (race ability, birthsigns). I will address these later (either during 0.09 or for a later milestone, depending on how fast we are progressing with the rest of 0.09).

There are still two problems left:

1. If I call EnableClassMenu twice, I am thrown into the Birthsign window (after finishing with the class window), even if EnableBirthsignMenu has not been called yet. Looks like a problem in mwgui

2. The last skill value for the player "NPC" in Morrowind.esm is currently seen as 100, while all other skill values are correctly set to 5. I think we have another problem with the ESM loader here. Maybe Nico could look into it?
amos wrote:
Zini wrote:1. If I call EnableClassMenu twice, I am thrown into the Birthsign window (after finishing with the class window), even if EnableBirthsignMenu has not been called yet. Looks like a problem in mwgui
This is actually how Morrowind works, I just copied its behaviour. Not sure if it matters one way or the other since you normally don't see it happening.
Zini wrote: Well, if that is how MW behaves, then we better keep this behaviour (who knows, there might be a mod out there that depends on it). We can address this issue post 1.0 (optional).
Zini wrote: One thing I forgot to mention regarding the character creation being almost complete. With this statement I mean the GUI and the game mechanics.

Playing through the actual character creation is not possible yet without using the console to fire up the character creation windows manually. There are still some missing script features, that need to be implemented. I am currently not planning to do that for 0.09, because we have another problem:

Most of the doors used during the character creation can't be activated yet. This is mostly the Ogre raycasting going wrong again. While I could work around it with coc, that would make testing an exercise in being annoyed. Also at the very end of the character creation there is a script, that requires proper collision detection. I therefore plan to defer finishing up this part of the implementation until the bullet integration is complete.
Zini wrote: I added a partial implementation for magic effects (resulting from race and birthsigns). For now only abilities are considered and only Fortify Maximum Magicka has any effect on the player.

I consider my work on character creation finished for now.

@amos: By accident I encountered a crash bug, that seems to be located in the GUI code. To reproduce enter EnableBirthMenu twice (without enabling any of the prior character creation windows).
amos wrote: Ok, I'll have a look and see what causes the crash.
Zini wrote: How is the GUI coming along? Haven't seen any commits from you for a while. AFAIK you are almost done, right? There may be some visual elements left to tweak and to add, but the core functionality is there. Is that correct?

I think the character creation GUI for 0.09 doesn't have to be perfect, as long as it is fully functional. I would like to start getting our combined changes into the upstram master branch rather sooner than later. Our branches have been running for almost a month without any synchronisation with upstream and the merge will probably not be trivial.

When you have wrapped up your current work, I will merge your gui-windows branch into my newchar branch. Then I will merge my newchar branch into my master branch and send a pull request to Nico. Is that okay for you?
amos wrote:
Zini wrote:How is the GUI coming along? Haven't seen any commits from you for a while. AFAIK you are almost done, right? There may be some visual elements left to tweak and to add, but the core functionality is there. Is that correct?
Didn't have much time for coding lately, hopefully I will have some time this weekend.
The GUI is quite close to completion (functionality wise), I just need to finish the various dialogs for Generate Class (multiple questions player has to answer).
I finally solved dynamic layout and sizing of buttons and text in MyGUI so I should be able to finish it.

Then I need to do the review page, I might just reuse the stat window for the 0.09 release and fix it properly after that.
Zini wrote:When you have wrapped up your current work, I will merge your gui-windows branch into my newchar branch. Then I will merge my newchar branch into my master branch and send a pull request to Nico. Is that okay for you?
Yup, sounds like a plan.
amos wrote: Just remembered. The display of spell powers is not finished, I will need a way to know which parts of a spell effect that is actually usable (range, duration etc.).
I was thinking of adding a function for returning this info based on a spell power ID, I'm guessing this is also needed when using the spell power?

Should we postpone this functionality to after the 0.09 release, or should I start making this function?
Zini wrote: Postpone it, yes. We can have a look at it later (probably much later).
Zini wrote: Tested the first class creation variant (questions asked) and I ended up at a class after only two questions. Is that correct? I don't know how exactly the process worked, but IIRC it was longer.

btw. I had to fix a gcc compatibility issue.

I think I will start the proposed merge now, even if the character creation GUI is still missing one step. Our branch collection is getting a bit complex and some of the merges already promise to get nasty.

Edit: Done. Pull request sent.
amos wrote:
Zini wrote:Tested the first class creation variant (questions asked) and I ended up at a class after only two questions. Is that correct? I don't know how exactly the process worked, but IIRC it was longer.
Only two pages has been implemented for now, I will need add the rest as well as the calculation of class (currently hardcoded).
You wouldn't happen to know if this info is available somewhere, so I don't have to figure it out myself. Might be on the mw wiki but haven't checked yet.

I got some work done on the stat review page yesterday, nearly finished with that one, should get it pushed later today.
amos wrote: Ok I pushed a bunch of changes bringing the character generation windows close to completion. I also merged with your master branch.

* Implemented stats review dialog.
* Fixed some dialogs to start with current choice/value.
* Update mechanism in WindowManager which is called each frame. Will be used to perform window/gui updates in the future, for instance getting rid of call to updateSkillArea() in mechanics manager.
* Cleaned up and unified dialog code quite a bit.
* All dialogs now use the dialog skin.

TODO for 0.09:
* Implement all questions for the generate class dialog. I found this page so it should be easy to get to this finished.
http://www.uesp.net/wiki/Morrowind:Class_Quiz

Other changes that is needed, we could easily skip them for 0.09 and do them for 0.10 or later.
* Make sure dialogs are modal, currently it is possible to click on another window while in a dialog. This should not be possible (except console). No idea if this is easy yet, need to investigate MyGUI more.
* Make sure hair and face scrollers are based on actual available hair and face meshes. Could easily be postponed as we don't show them yet.
* OK/Next buttons for generate class dialog must work like the other dialogs.
* Create dialog should start with values from the current class (custom or picked)
* Merge stat window and stats review dialog.
* Pressing enter in any dialog should trigger OK/Next button.
* Making sure all lists are sorted.

I'll update status page tomorrow with new screenshots and more info.

It would be nice if someone could try these dialogs and see if there are any serious bugs left.
Zini wrote: I gave it a quick test run and couldn't find any problems.

There is one point you should add to your to-do list though. The screen area for some of the labels is too short. The text is cut off (I presume only for longer than English labels).
amos wrote: Which of the windows does it happen in?

In general there is a problem with hardcoded sizes for certain elements, for instance all buttons are currently hardcoded. I alredy have this on my GUI TODO list. But do you think it needs to be fixed for 0.09?
amos wrote: I've added all the questions for the generate class dialogs and implemented matching of the answers to a class.

The only thing is that there are some combinations of answers which does not result in a class, rather I throw an exception now. If we want this correct we will need to go trough all combinations in Morrowind and add it to the wiki (UESP or ours). Unless someone has the possibility to do this I will have to have a look it next week.