No s**t??? Does it mean those guys have
source code?
And yes, when u post things like that always
link!
EDIT:
Confirmed. The new patch makes the game run smoothly.
Bad news, however. They use version 1.7, as I feared. This means - retarded AI in skirmish. Imp fights. Yay.
I wonder if I should write them a nice letter about the limitations of their contract with EA. Maybe we can work this out somehow. If they have access to game code, we may have a very small chance of convincing them to fix the AI issue or provide us with SDK. A nearly zero chance, mind you. However, looks like it's the best we can get now after all these years.
EDIT2:
Editor is also of the "latest" version, meaning no hatchery/lair. I desperately tried to do some hex editing on the files, trying to make the in-game variables work (keeper variables) - failed miserably. This game version is fubar.
EDIT3:
Interesting finding I just did. As a matter of fact, the maps totally IGNORE the (mapname)Variables.kld file. The game checks for the file existence, but it never uses the contents! I blanked out (NULL'ed) the whole file and guess what? The game worked perfectly fine. However, when you create a GLOBALS file, they use DEFAULT values of keeper properties, even if you modify the keeper. The keeper properties are correctly saved to the Variables file. If you do not create the global file, the game will read the default global file.
In simple words: whatever you do, the game will never see the changes for the keeper. What kind of retarded s**t is that.
Game file load priority:
Globals (map, stores DEFAULT Variables for keeper, never modifies them)
Variables (that do not work, store PROPER modification to the keeper)
Globals (default, stores all stuff in the world)
There is a possibility that I am wrong, and the Globals do not store the Variables for keeper. Then the priority is as following:
Globals (map, stores units, objects, spells, but not keepers)
Variables (that do not work, store PROPER modification to the keeper)
a. Globals (default, stores all stuff in the world (including the keeper)
b. Hardcoded Variables (this file may exist inside the game code, in this case, it stores all Variables info about keepers, default Globals doesn't)
In any scenario, these are the logical conclusions:
a. keeper properties are modified and saved correctly (unlike was thought before, editor DOES make the changes to the file)
b. the Variables file is never used, because another file has a higher priority, or the external read command fails on the file
Possible solutions:
a. find and modify the Variable/Global file in resources permanently
b. find a way to make the external Variables file readable.