[CommanderDJ]

I solicit your help once again, HLP.
I am getting major weirdness happening with the second mission of my mini-campaign. This is pretty much the only hurdle delaying release at the moment. In the second mission (which is not a red-alert mission, but IS set to have no briefing) Alpha 1 (the player) spawns with no weapons whatsoever, neither primary nor secondary. After watching from my wingmen's point of view, I'm pretty sure that the rest of Alpha wing spawns with no weapons either. And it does not seem like just the weapons are missing, but it's like the game doesn't recognize that the fighters can use weapons, as using set-primary-weapon and set-secondary-weapon SEXPs does not have any effect (I tried using both when-true, and when-key-pressed), and using cheats to force weapons to change gives the message that they have been forced, but no weapons actually appear. This does not occur when I test the mission as a single mission in the tech room, but only when put together with the others into a campaign. The first mission IS a red-alert mission, so that might have something to do with it, but no ships are set to Red Alert Carry Status in either the first or second missions. Running a debug build gives no errors at all. I am running the 3.6.12 Inferno SSE2 build with the 3.6.12 MediaVPs. My "mod" (it's only a few tables, and three models and a few weapons brought over from FS1) uses the MediaVPs as a secondary mod.
I'm running Windows XP on an Intel Core2 Duo E8400 processor and an NVIDIA GeForce 9600GT graphics card.

I have attached pix for proof. In the screenshot you will see that the player has no weapons. The "completed" Press U directive seen at the top of the directives window was set to trigger two set-primary-weapon SEXPs. Obviously it didn't work. Also in the top left corner you will see that I have attempted to use cheats to force my primary weapons to no avail.

fs2_open.log attached for great justice.

Thanks in advance for your help. I would really like to get this resolved/fixed so that I can finish my final testing of my mini-campaign and finally release it to you all.
I will keep working at this and update this post if I come up with anything new.



[attachment deleted by admin]

[General Battuta]

Did you allow the required weapons in your campaign file and check to make sure they're actually on the loadout screen?

[CommanderDJ]

I had not allowed them in the Campaign file, but after allowing them there is no change, unfortunately. Still no weapons. And the mission is set to have no briefing, so there is no loadout screen.

[karajorma]

Did you restart the campaign after allowing them? The game only reads in the allowed weapon at the start of the campaign. Changing them after that will have no effect.

[General Battuta]

Yeah, you need to restart the campaign for it to take effect. I'll bet that was the problem.

[FUBAR-BDHR]

You may even need to go as far as creating a new pilot file if restarting does not help. 

[CommanderDJ]

Ah, yes. Restarting the campaign didn't work, but trying it with a delicious new pilot worked out fine. Thank you, Master Overlords Battuta, karajorma, and FUBAR-BDHR. May HLP be blessed by your presence for millennia to come.

On another note, I will likely encounter other errors in my final testing stage. Is it alright if I just post them here? Saves me having to create new threads.

[CommanderDJ]

I've run into another problem. Repeatedly I've found that even though I haven't changed any arrival cues, the arrival cues of Alpha wing are randomly all set to false. This results in alpha wing not appearing (although the player still spawns) and other bad things happening. That's not the point, though. I just went and fixed one of these errors, and when trying to run the fixed mission with a debug build, I got this during the loading screen:

Code: [Select]

Assert: num_to_create == 0
File: missionparse.cpp
Line: 3852

<no module>! KiFastSystemCallRet
<no module>! WaitForSingleObject + 18 bytes
<no module>! SCP_DumpStack + 354 bytes
<no module>! WinAssert + 208 bytes
<no module>! parse_wing_create_ships + 2278 bytes
<no module>! post_process_ships_wings + 469 bytes
<no module>! post_process_mission + 49 bytes
<no module>! parse_mission + 1531 bytes
<no module>! parse_main + 449 bytes
<no module>! mission_load + 215 bytes
<no module>! game_start_mission + 198 bytes
<no module>! game_enter_state + 482 bytes
<no module>! gameseq_set_state + 310 bytes
<no module>! game_process_event + 242 bytes
<no module>! gameseq_process_events + 152 bytes
<no module>! game_main + 782 bytes
<no module>! WinMain + 330 bytes
<no module>! __tmainCRTStartup + 358 bytes
<no module>! WinMainCRTStartup + 15 bytes
<no module>! RegisterWaitForInputIdle + 73 bytes

When I pressed OK to break into debugger, the game crashed to the desktop.

I've attached an fs2_open.log

Halp?


[attachment deleted by admin]

[The E]

*Psychic debugging powers activated*

Are you doing a lot of wing editing?

I mean, you seem to be doing something here in a way that FRED doesn't like. You really should get into the habit of using debug FRED, I think.

[CommanderDJ]

Nope. All I did with wings was set their arrival/departure cues, personas and initial orders.

So where have I ****ed up to cause this error? Or do you need more information?

I'll try using debug FRED and seeing what that comes up with.

[The E]

More info is definitely needed here. The mission that causes this assert may help as well.

[Goober5000]

randomly

I do not think that word means what you think it means.   The error is predictable and reproducible, is it not?

Anyway, the arrival cues for all fighters in a wing are always set to false.  This is because the arrival is governed by the wing itself, not the individual ships.

[CommanderDJ]

More info is definitely needed here. The mission that causes this assert may help as well.

Well, just let me know what info you need from my end and I'll provide whatever I can.

The mission's pastebin is here.

randomly

I do not think that word means what you think it means.   The error is predictable and reproducible, is it not?

Anyway, the arrival cues for all fighters in a wing are always set to false.  This is because the arrival is governed by the wing itself, not the individual ships.

I have seen no pattern in it, but then again I haven't been looking for one. That's not what's hindering progress here anyway.

[FUBAR-BDHR]

I see Alpha 2 is the player ship.  There could be a bug here after all.  I helped someone else fix the same issue recently.   

Set the arrival cues to false on the ships, change the special ship to alpha 2 in the wing and see if that fixes it. 

[CommanderDJ]

No change by changing the special ship, but I've something out. When all arrival cues on the ships of Alpha wing are set to false, the assert does not show up, but none of Alpha wing appears in the mission apart from the player (Alpha 2). When any of the arrival cues of the ships in Alpha wing are set to true, the ships do show up in the mission (using the release build), but the debug build produces the assert. If I try and break into the debugger after the assert appears, I get a crash to desktop.

[pecenipicek]

shouldnt you be punting the arrival cues into the wing itself, not the ships?

[headdie]

A false arrival que means the ship or wing wont arrive.  if ships are in a wing arrivals should be handled by the wing and not the ship as you will brake things

[CommanderDJ]

That's exactly the problem though. The wing's arrival cue is set to true, but the wing doesn't show up. When I set the ships in the wing to true, they show up in release, but in debug I get the assert.

[pecenipicek]

That's exactly the problem though. The wing's arrival cue is set to true, but the wing doesn't show up. When I set the ships in the wing to true, they show up in release, but in debug I get the assert.

we can has the mission in question?

and a screenshot of the arrival cue itself.