Application: mellotanica

[mellotanica]

i'm sorry to bother you again, i hope this is the last time.. there are a couple parameters that are giving me a headache from the npc record. in the tracker issue it is stated that

If there are content files that contains invalid negative values (value range does not exceed 127, negative value not allowed but used anyway) we still need signed to be able to detect these properly.

so, if the maximum value in range for byte entries is 127, i could easily set all the unsure parameters to signed chars?

the fields in question are reputation value (the opencs validator checks if this value is below 0, but a comment says that there are no npcs in morrowind.esm with negative reputation, so that is assumed invalid) and the skill list, mSkills (this one is an array of base skill attributes for npcs, when loaded, the actual npc will have the skill value determined by

Code: Select all

actualSkill[i] = std::max(0, mSkill[i])

so i think it's useless to have negative values here).


i assumed those two parameters as unsigned, but i'm totally unsure about my choice.. should i check tribunal.esm and bloodmoon.esm as well as some random plugin files or there is a easy answer to my doublt?

[Zini]

i assumed those two parameters as unsigned, but i'm totally unsure about my choice.. should i check tribunal.esm and bloodmoon.esm as well as some random plugin files?

That would be great! Of course we don't expect you to do a thorough survey of all MW mods ever created, but checking the 3 default esm files plus some random user generated plugins has at least a decent chance to turn up the worst offenders in regards to out of range values in ESX records.

Of course if it turns out that you can use an unsigned type in the example you have given, you should also modify the validator accordingly.

[mellotanica]

ok, i think i'm finished, i found a little bug in http://www.uesp.net/text.shtml?morrow/tech/mw_esm.txt, the order of NPDT fields is wrong in the case of 52 bytes record, so i sorted the parameters in NPDTstruct52 (i'm assuming by the method used to load the structures that the declaration itself decides wich raw values go into wich field, am i right?)

everything that is not an unknown parameter and was a generic char is now signed or unsigned.

i'll attach a simple program that i wrote for checking data files, if someone will ever try to do a similar check again it should be easyly editable.

may i submit the pull request?

[Zini]

Sure. Go ahead.

[scrawl]

I posted some comments to the pull request, but I have some non-code comments as well.

Do not ever use mw_esm.txt. There are mistakes in it all over the place. Whenever you find a discrepancy, you should first assume that OpenMW is right. With that said mw_esm.txt is pretty useless, so again don't look at it.

i'll attach a simple program that i wrote for checking data files, if someone will ever try to do a similar check again it should be easyly editable.

We already have a tool for printing ESM files (esmtool). It would have been much easier to modify esmtool to do what you want, rather than writing a new tool.

[mellotanica]

well, it didn't take me that long, but i promise to use emstool next time!

about mw_esm.txt, i did see it is widely wrong, i did understand the lesson i think..

[Zini]

Okay. With that concluded, another task? There is still the other one I offered you.

Or if you want something more complicated:

* Editor: Subviews are deleted on shutdown instead when they are closed
* Editor: File->Exit only checks the document it was issued from.
* Editor: Documents are not removed on closing the last view

I suspect at least some of them are closely related. The close/shutdown logic of OpenCS seems to be messed up pretty badly.

[cc9cii]

Sorry, I already started to work on a couple of these. Let me know which ones you're working on and I'll stop.

* Editor: File->Exit only checks the document it was issued from.
* Editor: Documents are not removed on closing the last view

[Zini]

First come, first pick. I am sure we can find a different task for mellotanica if he doesn't want the other one offered.

[mellotanica]

i'm sorry for being late, i had some busy days.. anyways, for me it is absolutely not a problem, i can pick the subviews issue, but i need carification about that.

does it mean that each subwindow inside the main window is not properly deleted until opencs is killed? or is it referred to the secondary main windows created with the "new view" menu entry?