Slight Problem

[Sirbomber]

I have neither the time to search for an answer to this or correct typos, so here goes.
Anyways, whenever I try to save/reload a mission, attempting to view the mission objectives has resulted in a crash on every attempt except one, in which random characters were displayed in place of the proper objectives.  Before saving, the objectives are displayed properly.  I won't be able to check for another 3-4 days, so don't ask for more info, please. Just try to help as best you can given the limited information I have time to give you.

Thanks.

[Hooman]

Ahhh. In a custom level?
 

[Brazilian Fan]

Maybe your installation is corrupted

[Sirbomber]

Ahhh. In a custom level?

Think this one through, Hooman. If it weren't in a custom level, than why would I be asking in the Programming Forum?

[Hooman]

Because we also patch to exe to fix the occasional bug in the original game.

Plus, if this is a custom level, then I really don't care to even attempt to tackle this problem without additional details. I don't know what you've done and I don't really care to speculate on any number of the possible ways you could have screwed something up. This is way too vague.
 

[vennom]

put the map ur having this trouble and any additional information possible =P

[Sirbomber]

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:

Code: [Select]

struct
{
    // Disasters
    Trigger Blight;
    Trigger SMeteors;

...

} SD;

And then:

Code: [Select]

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:

Code: [Select]

    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!

[Hooman]

That looks fine. You don't need to save all the triggers, just the ones you need to reference later. Remember that the exported Trigger class is only a handle to the real trigger. All of the real ones will always be saved. You just need to save handles to the ones you'll modify after setting them up, such as in a trigger callback, or somewhere in AIProc.


A crash address might be nice. Plus more details about what is being saved, and what is being used. Well, more like what is not being saved. Sounds like you're using something that is only initialized properly in InitProc and is not saved in the struct.
 

[Sirbomber]

I'm saving most, if not all, triggers.  Right now, I only have triggers related to disasters and victory conditions, both of which BlackBox told me to save.

According to the Windows Error Report thing (I'm using Plymouth Cold War now, since everyone should have that), the crash address is 0x000(etc)4c68a2.
As far as I can tell, I'm saving the trigger but... maybe not the victory condition part? I'm just not sure what's causing the problem, really.
Then again, if I knew what the problem was, I wouldn't need to ask for help.

[Hooman]

Ok, the crash occured during a string processing routine. Looks like it's from a standard C library. Seems to have crashed while looking for the null terminator.

Perhaps you overwrote a string? Or maybe you wanted to dynamically create a text string that can change? I'd like to see all the code relating to the strings that get corrupt. If that's not the problem, then you might have a pointer error somewhere. If it's a pointer error, it may be a little harder to find. Especially without complete source.
 

[Sirbomber]

Alright, I PMed it to you. Don't go giving it out or anything.

[Hooman]

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:

Code: [Select]

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.
 

[Sirbomber]

My failure conditions are needed for the entire mission.  That way people fail if they decon their CC/SF.

No idea what's causing the problem, eh? Maybe I can ask Eddy-B... Assuming Renegades doesn't also have this problem.

Edit: Yes, Renegades saving/loading works properly. Now hopefully I can contact Eddy-B...

[BlackBox]

If I remember correctly, there is a limit of 255 active ScStubs in the mission at one time. This got further split up I believe, where you could only have 127 Triggers and 128 Groups / Pinwheels (or something to that effect).

I guess my recommendation would be, when you are totally done with certain triggers, call the Destroy() method on them to remove the resources associated with them (and free up that trigger for later use).

Keep in mind also that a victory / failure condition is also a trigger in itself.

[Sirbomber]

There's no way I'm using 127 triggers.
Besides, the triggers work fine until AFTER I load a saved game. When I'm playing the mission for the first time, everything runs flawlessly.

Again, your very own Plymouth Cold War has this problem, BlackBox.

[Hooman]

Yeah, you're definately not over the known limits. I was thinking perhaps something specially pertaining to victory/failure conditions.

Another thought might be some of the recent exe patches. I'm wondering if maybe the unit limit patch has something to do with this. I did have to make a few changes to saving and loading, so maybe the problem lies there.

Oh, and I wasn't worried about the CC. I was worried about the number of Convecs you needed to stay alive. Seemed a little silly. (I assume once they've built some cargo, you won't need them all).
 

[Sirbomber]

Perhaps, but we're getting off-topic. Eddy-B says he may have a solution, but I can't test it right now. I'll get back to you when I can.

[Hooman]

So any details on the possible causes and solution?
 

[Eddy-B]

I gave him advice about how i store game variables, including custom events that i worked on during Renagades' coding.

The solution was to put all global vars into a seperate data segment, and using the entire segment as a SaveRegion. That way, anything that isn't stored automaticly by OP2 (like pointers to a trigger) is saved along with the SaveRegion.

I haven't heard from Sirbomber yet this week...

[Sirbomber]

Well, as Hooman said in a PM, your method provides a solution, but doesn't really address the problem...  I kinda want to know why this problem is happening and solve it, not just work around it.

[Hooman]

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:

Code: [Select]

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.

Code: [Select]

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.