You should be able to open it with any tool that works with SQLite. I'm on a Mac and use MesaSQL, but I'm sure you will find a Windows tool that will open it!
I tried opening it with SQLite Database Browser, but the filtering seems a bit... er, wonky. BaseHP ≥ 150 gives me values anywhere from 2 to 1000. But it is apparently filtering something.
When viewing in Microsoft Excel, the returns from BaseHP ≥ 70 state 2075 in total across both games; 238 from BG:EE and 1837 from BG2:EE.
Can there be more than one copy of the file "MEPHSP1" containing different data?
Please note that when I give you the list tomorrow, it will contain both games. Like I said on the previous page, a creature using the resource 'XZAR' appears in both but with different stats.
Should they be unique per game? Absolutely. That will require you to create two databases or tables (one for each game) if you want a complete database.
At the moment, all the fields are text fields, which means the ordering is incorrect for numeric values. I could hardwire the types or you could specify them in the export file maybe?
We could add a line after the first line, with a list of the types,
e.g.
Line 1 - Name,Resource,BaseHP,...,...,... Line 2 - string, string,integer,,...,...,... Line 3 - NameData,ResourceData,BaseHPData,...,...,...
Alternatively the type could be appended to the field name,
I can export using whatever method is most convenient for you. If the latter is easier, then so be it. If the former is easier, then I can do that instead. It's only an extra bit on my end in the source code. It writes the first line, "Name,Resource,..,..," then cycles through everything on the list. So it is literally up to you to pick something and let me know. :-)
We can invent our own types to a certain extent, I can map them properly before creating the table, so my suggestion is:
string - any text - UTF8 integer - a string representing an integer hexmask - a string in hexadecimal notation that represent a bit field. hexdata - a string that represent a hexadecimal number. float - a string representing a floating point number.
For numeric values, we could extend it like so, Inteligence:integer(5..30)
Where the number in Brackets is the range allowable for that field (in this case from 5 to 30), I could write these values into "internal" fields and then they could be used by other apps to determine a valid range for the field. What do you think?
Another question, are the experience points stored as the BaseHP? If so then how large can this number get?
The two are not the same, Base HP is a WORD and experience is a DWORD and so those basic limits must obviously apply.
I have a question of my own. I'm making the last few columns string representations of their integer value—do you want me to include the actual value as well and, if so, in what format?
You should be able to open it with any tool that works with SQLite. I'm on a Mac and use MesaSQL, but I'm sure you will find a Windows tool that will open it!
I tried opening it with SQLite Database Browser, but the filtering seems a bit... er, wonky. BaseHP ≥ 150 gives me values anywhere from 2 to 1000. But it is apparently filtering something.
When viewing in Microsoft Excel, the returns from BaseHP ≥ 70 state 2075 in total across both games; 238 from BG:EE and 1837 from BG2:EE.
When viewing in Microsoft Excel, the returns from BaseHP ≥ 70 state 2075 in total across both games; 238 from BG:EE and 1837 from BG2:EE.
I didn't see this before, the reason it's wonky is because in the initial version, I made all fields TEXT fields which have a different collation order, this should work ok once we have the right types for each field.
I'm not sure what you mean? Do you mean have two fields, one with the Integer value and one with the String Value?
Something like that, or having a field that can be split, e.g., Human - 1. Where ' - ' would be a delimiter that can be used to split the field between the text and the actual value. You mentioned being able to export; you will not be able to export without the actual values. In the example above, you could split the value and use only that when exporting. If this is not important, then I'll leave everything as is and upload the list for you.
I didn't see this before, the reason it's wonky is because in the initial version, I made all fields TEXT fields which have a different collation order, this should work ok once we have the right types for each field.
It was the same even after setting the fields to 'NUMERIC'. I would assume that it is still seeing the values as TEXT.
Not sure what you mean? The table has to be created from the export file, with the correct type definitions, then when a record is inserted, if it a numeric field, it auto-converts the string to an Integer (INT in SQLite), (I use NUMBER if you specify a float type, as in Name:float) if it can, otherwise gives an error. I haven't run the Tool with the new list, do you post a new file with the types specified?
The other way around the number as text problem is to left pad the number with zero's, but this takes up extra space in the database and if used for an index/key will slow it down.
Here is the latest file, this one has the correct INT type for BaseHP so you can use numeric operator on them like BaseHP > 100 or BaseHP <50.
I hard tweaked the Export file so it contained integer type instead of string. I've attached that file too, look for the BaseHP:integer in the first line.
Comments
When viewing in Microsoft Excel, the returns from BaseHP ≥ 70 state 2075 in total across both games; 238 from BG:EE and 1837 from BG2:EE.
Should they be unique per game? Absolutely. That will require you to create two databases or tables (one for each game) if you want a complete database. I can export using whatever method is most convenient for you. If the latter is easier, then so be it. If the former is easier, then I can do that instead. It's only an extra bit on my end in the source code. It writes the first line, "Name,Resource,..,..," then cycles through everything on the list. So it is literally up to you to pick something and let me know. :-) I only uploaded for BG2:EE, not BG:EE.
Name:string,Resource:string,BaseHP:integer,...,...,...
We can invent our own types to a certain extent, I can map them properly before creating the table, so my suggestion is:
string - any text - UTF8
integer - a string representing an integer
hexmask - a string in hexadecimal notation that represent a bit field.
hexdata - a string that represent a hexadecimal number.
float - a string representing a floating point number.
I think that about covers it?
Where the number in Brackets is the range allowable for that field (in this case from 5 to 30), I could write these values into "internal" fields and then they could be used by other apps to determine a valid range for the field. What do you think?
Valid would be: Bit32, Big16, Little32, Little16, not sure if we need 64 bits?
Another question, are the experience points stored as the BaseHP? If so then how large can this number get?
FieldName, is equivalent to FieldName:string,
Cheers
Dave
I have a question of my own. I'm making the last few columns string representations of their integer value—do you want me to include the actual value as well and, if so, in what format?
I didn't see this before, the reason it's wonky is because in the initial version, I made all fields TEXT fields which have a different collation order, this should work ok once we have the right types for each field.
I hard tweaked the Export file so it contained integer type instead of string. I've attached that file too, look for the BaseHP:integer in the first line.