[redmenace]

Actually that is exactly what happened. I had called in support and it was coming very close to me before I jumped out. Like 2 seconds away maybe.

[Goober5000]

Hmm... I think I know what the problem is then.

Would you mind running a bunch of tests for me? If you would, try jumping out at various points before the support ship gets to you (say, three... when it arrives, just before it docks (which you already did), and in the middle).  See which ones crash and which don't.

[redmenace]

I will create a custom mission then and do that later after I come back from the hardware store

[taylor]

It's the same basic problem as the jump-in dock crash from a couple of months ago.   I did test that a little and the support ship did have to get rather close for it to mess up.  At that point the ai goal would be reset since the ship was effectively gone.  There is no check in the docking code to handle aborts from that as far I know.

So basically it can and does happen, there is simply no check to guard against it.  At least that's what it looks like to me after going over the code.  Same thing that happened last time where the docking request would come in just as the ship was warping in but the ai goal was -1 until after the full warp-in sequence had completed.  I am pretty hesitant to put a NULL check in this one though since that's obviously not the best fix but would certainly get the job done.  I'll just leave this one to you then Goober.

[redmenace]

Ok, I was able to recreate the one crash but found no others such as while on approach and while rearming(while rearming I found that it would just abort rearming and abort the warp out sequence.). If one wishes to recreate it, i would suggest that you go in loops with the support ship very near and while doing so warp out when it is very near.

[Goober5000]

Originally posted by taylor
It's the same basic problem as the jump-in dock crash from a couple of months ago.   I did test that a little and the support ship did have to get rather close for it to mess up.  At that point the ai goal would be reset since the ship was effectively gone.  There is no check in the docking code to handle aborts from that as far I know.

So basically it can and does happen, there is simply no check to guard against it.  At least that's what it looks like to me after going over the code.  Same thing that happened last time where the docking request would come in just as the ship was warping in but the ai goal was -1 until after the full warp-in sequence had completed.  I am pretty hesitant to put a NULL check in this one though since that's obviously not the best fix but would certainly get the job done.  I'll just leave this one to you then Goober.

Is this the old crash bug you're referring to?  Because I don't think these are the same things.

I think this might be a bug in the goal system... the "rearm" goal is removed but the support ship is still in the "dock" mode.  Redmenace, can you replicate this bug in any other build?

[DaBrain]

Originally posted by taylor

The current release or the beta?  I haven't had any problems with the current release but please send an errorlog.txt or something so I can figure out what's wrong.  That one errorlog that Trivial Psychic posted gave me a clue that has been fixed but I don't know why it would have gotten to that point in the first place.  I'm making a couple of OpenAL changes now so perhaps that will fix it.

Beta, or even worse. I've messed a lot around with it.

I'm right now downloading the newest staff beta. I'll see how it works.

Edit: It works now.
Looks like I screwed up too much before.

But sometimes the sound, when my is hit, is too loud.

Other than that it worked fine. Maybe it's the Beta pack. I didn't check it's sounds.

[taylor]

Originally posted by Goober5000
the old crash bug you're referring to?  Because I don't think these are the same things.

Yeah that's the bug to which I was referring.  It's a different instance of the same problem.  The problem code isn't taking into account that the goal system either isn't set or got reset while still trying to execute.  The goal system isn't setup for a ship that is just warping in.  When the warp in proceedure is done then it's setup but with that other bug it would try and process the ship before that point.  That bug was because  it would keep looping through until it got into the dock mode, the fix was to avoid that case until the goal system had been readied.

This new problem is the same thing, when the warp out proceedure gets to a certain point the goal gets reset but it will still try and process the docking mode.  The extra NULL check in this case would prevent it from contiuning to dock at this point but the better fix would be, as you mention, to make sure that docking is aborted when the rearm goal is removed.

The old way took all of this into account I believe.  I don't know if it was intentionally handled but it did work.

[Goober5000]

mmph... the trouble is, I don't think there *was* an old way.  I didn't change much of the goal code, so I don't think this would have been changed all that much.

[taylor]

Originally posted by Goober5000
mmph... the trouble is, I don't think there *was* an old way.  I didn't change much of the goal code, so I don't think this would have been changed all that much.

You know the code better so I'm reaching a little in my description and that may be a bit confusing.  I'm interpreting the code based on the observed behavior and the previous bug fix rather than a real understanding of your changes.

The main thing I notice that's different, and what we both notice as wrong, is that a rearm abort doesn't signal undock.  Looking in the icculus.org code (since it's untouched here) I see that you split ai_cleanup_dock_mode() into a rearm version as well as a dock version.  Missing from the rearm part is this block of code:

Code: [Select]

   if ( aip->ai_flags & AIF_DOCKED ) {
        ai_info *other_aip;

        Assert( aip->dock_objnum != -1 );

        // if docked, and the dock_objnum is not undocking, force them to near last stage
        other_aip = &Ai_info[Ships[Objects[aip->dock_objnum].instance].ai_index];
        if ( (other_aip->mode == AIM_DOCK) && (other_aip->submode < AIS_UNDOCK_3) )
            other_aip->submode = AIS_UNDOCK_3;
        ai_do_objects_undocked_stuff( objp, &Objects[aip->dock_objnum] );
    }
I don't know the current equivalent of AIF_DOCKED but the submode is getting reset here so that could be the difference.  I haven't really looked at your other changes though so this check may be redundant or just wrong with the new code.  I would guess that something similar is needed though.

[Goober5000]

Oho, very interesting.  That's exactly what it is; I didn't think of that when I split the two functions.  That'll get committed right away.  Thanks.

[Nuke]

i havent been able to make a new build work with nukemod sence wc's  fs2_open_C03122005_o.exe build. i think it has something to do with the most recent changes made to the ships table parsing code. its not seeing the $ai class: entry for some reason. its also not reading the flags.

[redmenace]

I have done some extra testing of the Mission The King's gambit. I got two seperate crashes.
This is the first.

[redmenace]

This is the second.

[taylor]

Originally posted by redmenace
3. Can't use debug with open GL when you get error messages and select no. You get a black screen.

Not really a fix but you should be able to ALT-TAB back to the desktop and then ALT-TAB back to the game.  It may take a couple of seconds but should become active again.  If that doesn't work let me know.  I'm looking for a code fix but this isn't very high on the priority list right now.

[Goober5000]

Originally posted by redmenace
This is the second.

This is the same as this bug.  Could you add your information?

[redmenace]

Originally posted by Goober5000
This is the same as this bug.  Could you add your information?

Done.

[redmenace]

I got a crash loading "Speaking in Tongues" from the techroom. I was using '-allslev' I had just played a few missions in a row including one repeatedly using Quickstart after dying. Attached is the relevant information.

[taylor]

Originally posted by redmenace
I got a crash loading "Speaking in Tongues" from the techroom. I was using '-allslev' I had just played a few missions in a row including one repeatedly using Quickstart after dying. Attached is the relevant information.

At least parts of this should be fixed in the 0530 update build.  Give that one a try, assuming that you want to play through that many missions again, and see if you get the same results.

[redmenace]

may 30 build? where?