Author Topic: Slight Problem  (Read 4329 times)

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Slight Problem
« on: August 27, 2008, 01:14:34 PM »
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.
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Slight Problem
« Reply #1 on: August 28, 2008, 07:57:00 AM »
Ahhh. In a custom level?
 

Offline Brazilian Fan

  • Sr. Member
  • ****
  • Posts: 302
Slight Problem
« Reply #2 on: August 29, 2008, 09:07:10 AM »
Maybe your installation is corrupted

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Slight Problem
« Reply #3 on: August 29, 2008, 12:29:42 PM »
Quote
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?
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Slight Problem
« Reply #4 on: August 29, 2008, 02:59:28 PM »
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.
 

Offline vennom

  • Jr. Member
  • **
  • Posts: 73
Slight Problem
« Reply #5 on: August 29, 2008, 06:34:53 PM »
put the map ur having this trouble and any additional information possible =P

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Slight Problem
« Reply #6 on: August 29, 2008, 08:10:22 PM »
Quote
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!
« Last Edit: August 29, 2008, 09:02:26 PM by Sirbomber »
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Slight Problem
« Reply #7 on: August 31, 2008, 08:01:02 PM »
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.
 

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Slight Problem
« Reply #8 on: August 31, 2008, 09:15:59 PM »
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.
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Slight Problem
« Reply #9 on: September 02, 2008, 10:33:13 AM »
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.
 

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Slight Problem
« Reply #10 on: September 02, 2008, 10:49:18 AM »
Alright, I PMed it to you. Don't go giving it out or anything.
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Slight Problem
« Reply #11 on: September 04, 2008, 01:44:11 AM »
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.
 

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Slight Problem
« Reply #12 on: September 04, 2008, 06:22:44 AM »
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...
« Last Edit: September 04, 2008, 06:28:14 AM by Sirbomber »
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
Slight Problem
« Reply #13 on: September 04, 2008, 11:44:30 AM »
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.
« Last Edit: September 04, 2008, 11:46:21 AM by BlackBox »

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Slight Problem
« Reply #14 on: September 04, 2008, 11:52:33 AM »
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.
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Slight Problem
« Reply #15 on: September 04, 2008, 04:35:26 PM »
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).
 
« Last Edit: September 04, 2008, 04:36:14 PM by Hooman »

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Slight Problem
« Reply #16 on: September 04, 2008, 05:58:00 PM »
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.
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Slight Problem
« Reply #17 on: September 08, 2008, 04:59:05 PM »
So any details on the possible causes and solution?
 

Offline Eddy-B

  • Hero Member
  • *****
  • Posts: 1186
    • http://www.eddy-b.com
Slight Problem
« Reply #18 on: September 13, 2008, 04:39:27 PM »
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...
Rule #1:  Eddy is always right
Rule #2: If you think he's wrong, see rule #1
--------------------

Outpost : Renegades - Eddy-B.com - Electronics Pit[/siz

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Slight Problem
« Reply #19 on: September 14, 2008, 04:38:14 PM »
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.
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Slight Problem
« Reply #20 on: September 15, 2008, 12:49:26 AM »
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.