Jump to content

sukhoi191

Accessing the position of "CraterOnVehicle" causes the game to crash

Recommended Posts

I'm probably about 20 years too late for sending OFP / CWA bug reports but here I am, doing just that.

 

Now, to be serious, I'm hoping someone might give me some idea why is it happening. To reproduce a crash, simply try to execute the following script:

crater = "CraterOnVehicle" createVehicle [0,0,0]
craterPosition = getPos crater

What causes the crash specifically is the "getPos crater" function call. Judging by the crash dump, the game tries to access a NULL pointer. It doesn't matter what position you provide for the instance.

 

It may seem like I'm really trying to find problems but it's actually a result of a thorough analysis of CWA crashes I got.

 

Recently, me and my friend happened upon some great crCTI missions. The only download link I could find is here if anyone's interested. After playing for some time on vanilla CWA I decided to try them out on FFUR 2007, specifically FFUR-SLX 2007 2.5.

 

In the crCTI missions I mentioned there is a function "Common\InForest.sqf" which contains a "while" loop. It seems to work like the "nearestObjects" known from ArmAs. In CWA, only "nearestObject" (singular) is available so it makes sense to write your own implementation of "nearestObjects" if you need it.

 

To keep things short, here's the important part:

while "_i < 100 && _c < 4" do
{
  _dist = 30*(_i/100);
  _dir = _i*20;
  _pos = [ _this select 0, [_dist*(sin _dir), _dist*(cos _dir)] ] call funcVectorAdd;
  // "Art0" setMarkerPos _pos;
  _object = nearestObject [_pos, ""]; // this is important

...and then:

if (((getPos _object) select 2) > 5) then

To summarize:

  1. "_object = nearestObject [_pos, ""]" might find an instance of "CraterOnVehicle" (which seems to happen regularly on FFUR but never on vanilla).
  2. "getPos _object" in the "if" condition causes a crash when _object is a "CraterOnVehicle" instance.

I have a theory why these crashes occur on FFUR 2007, but not on vanilla: FFUR adds much more effects like flames and smoke. Perhaps it is creating "CraterOnVehicles" instances more freely than vanilla, and so the "while" loop is much more likely to find one.

 

I know it can be easily fixed by skipping "CraterOnVehicle" instances in the while loop, I'm just curious if anyone has any idea why is it happening in the first place? Also, I was able to find more objects causing the same crash (e.g. "Crater") so knowing the reason for this issue would be very helpful in pinpointing any other potential trouble-makers which should be excluded from the loop.

 

Here's how they both look like in config.cpp:

class Crater
{
    model="";
    simulation="Crater";
};

class CraterOnVehicle
{
    model="";
    simulation="CraterOnVehicle";
};

Obviously, my first idea was that the "model" is empty so maybe this was the culprit, but I quickly found an example proving otherwise:

class Track
{
    model="";
    simulation="track";
};

When I create an instance of "Track" and call "getPos" on it, it correctly returns the position, so empty "model" isn't the reason (at least not by itself).

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

I also recently found a bug with getPos "CraterOnVehicle". It can be bypassed using the command getPosASL "CraterOnVehicle".

Some objects such as class  "Track" /  "Mark" are placed on the ground surface, their vertical position (getPos select 2) is always = 0.

But the "CraterOnVehicle" has a vertical position relative to the ground surface > 0. It seems that game engine cannot calculate getPos "CraterOnVehicle" select 2 and crashes.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for the info, that's interesting. I took all the class names from CfgNonAIVehicles and repeated the same test just to see which ones will crash, which will retain position Z, and which will reset to [0,0,0]. Here's the results:

 

  Reveal hidden contents

 

It looks like it's safe to use getPos as long as you avoid a couple of specific classes. Of course, it's possible that there are other classes which will cause the crash (I tested only the ones in CfgNonAIVehicles) but for now it should be enough to fix the mission.

 

If anyone wants to check it out, here's the script I used:

 

  Reveal hidden contents

 

  • Like 2

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×