[Goober5000]

I'm not talking about the Mods I'm making or working on.  I would most certainly fix those and wouldn't turn it off on a campaign I'm working on.  I'm talking about some mod I'm playing that someone else wrote ten years ago and never generated any error messages until this latest revision.  I'm talking about errors that are generated from the fact that when the original author checked all the weapons in the mission loadout including the dogfight versions but didn't include that in the campaign file.  I'm not particularly anxious to go back and fix every error in every campaign that's been written since 1998.  I just want to be able to turn it off.

If we allowed you to turn it off (which we're not going to do), everybody would turn it off and the feature would quickly become useless.  Human beings are extraordinarily lazy creatures, so sometimes annoying them is the only way to get them to fix things.

As for historical mods that have problems, that's hypothetical for the time being.  Unless we run into a mod that triggers the warnings, we won't have any idea of its impact.  And regardless, historical mods can be patched.  Look at Derelict, or any of the FSCRP campaigns.

[Macfie]

I have on the order of about 184 campaigns in my FreeSpace Flies.  I'm probably not in my lifetime going to restore all those campaigns.  Derelict and most of the campaigns we've restored at the FSCRP are worth the effort. a lot of those 184 campaigns I've got are probably not worth the effort.  Most of those did not generate any errors until recently because I fixed the showstopper bugs. The majority of the errors identified have absolutely no effect on the ability of the campaign to work.   All the inconsequential warnings just cloud the issue and are like the boy crying wolf.   After a while if I can't turn them off I'll probably just ignore them.   I have absolutely no problem with the debug version identifying those errors but if I just want to play the campaign I really don't care. 

[Getter Robo G]

Soumds you and I have had similar problems... I've worked on mods for two previous older builds and you can't just plop old data over to new... It generates errors that might not have been errors at the time.

Worst case scenario: keep your old data, but not import it.

You'll have to redo all the data that's actually critical to the ships over NEW SCP entries (just like I had to do). There was no way I was going to track down 192+ errors when I had no idea wtf it was even talking about in the first place and had nothing to do with me personally.

Luckily FS2 IS rather easy to Mod even with limited knowledge. As for me I only mod enough stuff in for TESTING purposes and never any real commitment. That means I restrict myself to WEAPONS and SHIP's tables only and occasionally make a effect.

Using tables (I know work error free) as a Template for  those things and then afterward going back and customizing them, and then yet MORE TESTING!

Testing is a very boring and vital thing in FS2 modding and cannot be rushed or skipped.

People often run into trouble when they start changing multiple things and then have no idea where to start when **** goes south... I learned that lesson myself painfully.


Good luck with your effort and trudge on soldier!

[SF-Junky]

It works... it really works...  I can launch debug build without any problems.

Thank you! Thank you to all of you.

One question about the Inferno builds: Can I just switch to them from normal builds or do I have to consider something special.

[Fury]

Old player files do not work with Inferno builds.

[Spoon]

Don't you feel all warm and fuzzy inside now that you got it all working?

[SF-Junky]

Don't you feel all warm and fuzzy inside now that you got it all working?

I do. But there is still a lot of work ahead.

I made another few changes in the *.tbl and *.tbm and now got this one:

Code: [Select]

Assert: wip->wi_flags & WIF_PARTICLE_SPEW
File: Weapons.cpp
Line: 3088


Call stack:
------------------------------------------------------------------
    parse_weaponstbl()    parse_modular_table()    weapon_init()    game_init()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 7c817077()
------------------------------------------------------------------


[Dragon]

I know this one, search for weapons with $Pspew defined and add "Particle spew" to it's flags.
I'm cetrain that you have at least one.

[SF-Junky]

You sure this is the problem? I added the flag to all weapons that have that pspew thing, but the errormsg is still there. I wonder why this should be a problem, anyway. The "particle spew" flag is already added to the weapons with $pspew in mv_effects-wep.tbm in the effects mediavp.

[Dragon]

I got exactly the same error and fixed it by adding "particle spew" flag to each weapon with $Pspew defined.
Double and triple check all custom weapons (if you have them), also watch for typos in flag (for example "particlespew" or "particle_spew").
You may also create empty ASCII file named "Debug_filter.cfg, put it into yourfreespacefolder/data and then run debug build and check the log (it will be much larger than before).
If you won't be able to figure it yourself, then search the log for "Assertion" and then post around 10 lines before and after assertion line (of course assertion line itself too).

[SF-Junky]

Code: [Select]

in weapon: Circe
Found required string [$Name:]
Stuffed string = [Lamprey]
Weapon name -- Lamprey
Stuffed string = [Lamprey_Bitmap]
Stuffed string = [Morningstar_Glow]
Stuffed float: 3.000000
Stuffed float: 3.000000
Stuffed string = [Lamprey_Impact]
Stuffed float: 1.900000
ASSERTION: "wip->wi_flags & WIF_PARTICLE_SPEW" at Weapons.cpp:3088
    parse_weaponstbl()    parse_modular_table()    weapon_init()    game_init()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 7c817077()
Int3(): From e:\storage\fso\fs2_open_3_6_10\code\globalincs\windebug.cpp at line 1075
These are the last lines of the fs2_open.log. "particle spew" has been added to the circe. Error still occures.

[Dragon]

It's a problem with Lamprey, not Circe.
I can clearly see the pulse and explosion dimensions and bitmaps from Lamprey, not to mention "Weapon name -- Lamprey"
Just add "Particle Spew" to it.

[SF-Junky]

The Lamprey has a "particle spew" flag. Or am I supposed to add the $pspew?

[Dragon]

Maybe, if it doesn't have $Pspew: , but have "particle spew" flag, maybe it can also be the cause.
Try adding it, when I got this error the problem was caused by missing flag, but maybe your is caused by missing entry.

[SF-Junky]

Okay, I'm now one step further.

What I am doing exactly is to move all $flags entries from the weapons.tbl to a .tbm in my mod. I deactivated the $flags in weapons.tbl by putting a ";" at the beginning of the line.

But it seems that I can't move the $flags from Lamprey, Standard Flak, Heavy Flak and Long Range Flak - as I see it right those are all the weapons that had the "particle spew" entry in FS retail. I moved the flags of those weapons back to weapons.tbl and now it works just fine again.

But an explanation would still be nice.

[SF-Junky]

Got this one while playing one of my missions:

Code: [Select]

Assert: vm_vec_mag(plane_normal) > 0.999f && vm_vec_mag(plane_normal) < 1.001f
File: VecMat.cpp
Line: 464


Call stack:
------------------------------------------------------------------
    fvi_sphere_plane()    mc_check_sphereline_face()    mc_shield_check_common()    mc_check_sldc()    mc_check_sldc()    mc_check_sldc()    mc_check_sldc()    mc_check_sldc()    mc_check_sldc()    mc_check_sldc()    mc_check_shield()    mc_check_subobj()    model_collide()    beam_collide_ship()    obj_check_all_collisions()------------------------------------------------------------------



[Wanderer]

Well... now... there is not much to go with that error... I would assume given the functions used that one of the ships in the missions which has shields has bad geometry in its shield mesh. Without attaching the debugging and checking which model causes the problem to appear it is very difficult to sort this kind of issues.

[SF-Junky]

That doesn't very serious to me, to be honest. More like some minor .pof problem, maybe?

Here is another one:

Code: [Select]

Assert: Weapon_info[Weapons[hobjp->instance].weapon_info_index].wi_flags & WIF_BOMB
File: Weapons.cpp
Line: 4745


Call stack:
------------------------------------------------------------------
    weapon_process_post()    obj_move_all_post()    obj_move_all()    game_simulation_frame()    game_frame()    game_do_frame()    game_do_state()    gameseq_process_events()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 7c817077()
------------------------------------------------------------------


[Wanderer]

Hmm... Assuming i'm looking at right spot that is caused by homing weapon trying to home on non-countermeasure and non-bomb weapon.