Quote:
Originally Posted by redsoxford
I'm also of the opinion it's one of the dat files that claims to have an ID field but the actual ID is something to do with its position in the file. I was doing some fiddling with my program and changed my internal structure for names from a Generic.Dictionary to a Generic.SortedDictionary to try something, forgot to change it back, saved the names.dat file.
It was exactly the same size as before, but when I ran the game all the names had changed...
|
For example, using Cubbys 08 set, this is the starting line-up for the Red Sox after I saved names.dat back without changing any of the data (just the order changed)
Josh Tristram
Curt Snoopy
Adrain Mongia
Julian Kishen
Tim Jesu
interesting that Beckett, Schilling, Tavarez and Wakefield all kept their first names but Dice-K became an Adrain...
Looking at the picture below you can see the names are in the same order in this small area, and after Pontifes in both cases you can see a3 ac 00 00 which is the ID of Pontifes (or at least it is if the ID numbers go up consecutively in the file).
Quite why you'd have a field that is unique per record and if cross compared to players or coaches gives the correct name (if saved in order) but actually isn't used because the real value it uses is the sequence number.
Either way, it's not right. If you have a unique identifier against a record then it should be used. If it's not being used (as is clearly demonstrated by my experiment) then what's the point in wasting 4 bytes per name on it?
Hopefully a lot of these database anomalies will be sorted out in OOTP9 - the name one is just as bad as the teams.dat issue where team_id is position in file, not the field called team_id...