This is way too vague.
And I apologize for that, but I had a very limited amount of time to describe my problem.
Anyways, I have lots of time now. What do you want/need to know?
I (thought) I had set up saving/loading properly (BlackBox helped me) but apparently not.
Here's some code:
struct
{
// Disasters
Trigger Blight;
Trigger SMeteors;
...
} SD;
And then:
void __cdecl GetSaveRegions(struct BufferDesc &bufDesc)
{
bufDesc.bufferStart = &SD; // Pointer to a buffer that needs to be saved
bufDesc.length = sizeof(SD); // sizeof(buffer)
}
I'm only saving triggers, should I also be saving Victory Conditions*? If so, how?
*I'm saving the triggers associated with the victory conditions, but not the conditions themselves. Yuck, I can't find a good way to say this. So:
SD.ET = CreateEvacTrigger(1, 0, 0, "None");
CreateVictoryCondition(1, 0, SD.ET, "Have enough Evacuation Transports for your population.");
Any suggestions?
Edit: Oh, by the way, Plymouth Cold War does the same thing. Try it! Load Plymouth Cold War, save the game, load the saved game, and try to check your objectives!
I didn't see anything obviuosly wrong with it. Perhaps it's an OP2 limitation that we don't know about yet. You do create quite a few triggers/conditions. My first guess is there is perhaps some limit to how many you can have active at one time.
Btw, you might want to double check your failure conditions. They might not be appropriate for the entire level. You might want to disable/destroy some of those later, or find a different way to do what you're doing.
If you need to fail the user after some special cased checking, you can create a time trigger, waiting 1 tick, which is the failure condition. Something like:
void CheckForFail()
{
// Check conditions here
// ...
if (bFailed)
{
Trigger &failTimeTrigger = CreateTimeTrigger(true, false, 1, "NoResponseToTrigger");
CreateFailureCondition(true, false, failTimeTrigger, "");
}
}
Then just call that function at a regular interval. Either make a call to it in AIProc, or make it the callback to a time trigger. Plus, if this failure check is only needed at say the beginning of the level, then you can disable/destroy a time trigger that has this as a callback when the check is no longer needed.
People may find this puzzling. Sirbomber sent me a DLL with the stated problem. I verified the problem. He sent me the source code used to make this DLL, and I compiled it myself (after a few slight changes to adjust it to my environment), and it runs perfectly. I sent him back my slight changes so he could try them in his environment, and it still has the said problem.
I used DevStudio/MSVC++ 6.0. Sirbomber used CodeBlocks/MSVC++ ? (whatever version the packaged contained).
Btw, if you have something like this:
struct
{
Trigger someTrigger;
// ...
} saveData;
It won't compile with MSVC++ 6.0. It gives a warning about the anonymous struct. It seems that the struct needs a name for the compiler to provide a default constructor. I suppose this has to do with name mangling and linking. Anyways, since Trigger has a non-trivial constructor, any struct that contains it also must have a non-trivial constructor. Thus, for the compiler (version 6.0) to provided the needed default constructor, you need to name the struct.
struct SaveData
{
Trigger someTrigger;
// ...
} saveData;
Note the "SaveData" after the "struct" keyword.
Of course this change didn't solve the problem. It only allowed it to compile under an older version of the compiler. My next best guess is perhaps a faulty support library. We played around with LibCTiny, but that had no effect on the problem. I suppose it did use other libraries though. I noticed a reference to IUnit, and OP2Helper. Maybe check if you're using an up to date version of IUnit, and it's corresponding .lib file. If that's not it, then maybe some strange extension to OP2Helper? I don't recall anything in there that should cause a problem like this though. Failing all that, it could also be some obscure compiler flag or something. Or perhaps even a compiler bug.
Of course this is assuming that binaries created with one version of the compiler will still work with binaries created with another version of the same compiler. I suppose it's possibly they could have changed a calling convention.