Zini wrote:
That would be great. Here is the issue
This was never a localization issue, it was just that the encoding for the esmtool was never set. And this tripped an assert. The strange thing is why nobody complained all this time. Probably a combination of nobody using it, and asserts being disabled in Release mode.
I've set the encoding to default latin encoding, I see that we are using a tool that sets up the command line arguments automatically so I left that alone for now.
Both commits are on github, time to look into the weapon records, and whatever else is missing.
#include <iostream>
using namespace std;
int main()
{
int a = 0x3fa66666;
cout << static_cast<float>(a) << endl;
cout << *((float*)&a) << endl;
return 0;
}
Zini wrote:See my comment on github please. A simple implementation via boost program options will do the job (no need for using cfg files).
I see that we are using a tool that sets up the command line arguments automatically so I left that alone for now.
I do not know what you mean with this.
When I said configured I meant through a command line argument, and from what I can tell the esmtool uses another tool called gengetopt that automatically generates the code to handle them. Regarding boost program options, I have to say I'm totally unfamiliar with Boost.
When I said configured I meant through a command line argument, and from what I can tell the esmtool uses another tool called gengetopt that automatically generates the code to handle them
I see. That is a ugly overcomplicated relict from the early days of OpenMW that should be thrown out as quickly as possible.
As for boost program option have a look at the main.cpp file of OpenMW.
werdanith wrote:This would not work. It was a number encoded as a float stored into an integer. Try this code and you'll see why:
Ok, but is there an alternative to your proposed solution with the ifs? Right now we only use two versions, but in the future we will add at least one more for the editor.
In the future we will need a new sub-record for the version info (of type int or something similar). I guess we can invalidate the current one by setting it to std::numeric_limits<float>::max() or something; which would indicate that the new version record should be used. That would make a total of 3 version numbers.
Using floats for version numbers is a really bad idea.
pvdk wrote:
Ok, but is there an alternative to your proposed solution with the ifs? Right now we only use two versions, but in the future we will add at least one more for the editor.
That's why I said I don't know what to do about it. This requires either the ESM_Context struct to be rewritten or a function that converts floats that pretend to be ints into real floats.
I tore out the gengetopt crap from the esmtool and replaced it with boost program options. The commit is up on github and it seems to be working correctly for me and pvdk.
Next I plan to look into the missing records.
And since I'm on a refactoring spree, are there any useful features, or interface revamp required for the tool?