Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: SF-Junky on July 20, 2009, 03:03:49 pm
-
Question about the new launcher: Is there a way to deactivate that "Your currently selected mod has XY errors"-message? Or is that part of the the executables?
-
Question about the new launcher: Is there a way to deactivate that "Your currently selected mod has XY errors"-message? Or is that part of the the executables?
Yea get your mod to fix the errors. I'm pretty sure that was why that feature was added.
-
Question about the new launcher: Is there a way to deactivate that "Your currently selected mod has XY errors"-message? Or is that part of the the executables?
In fact, aren't you on the team that's supposed to be fixing those errors? :)
-
To be honest, it's an extremely useful feature in my opinion, there aren't that many games that will help with error-checking Mods for you, certainly not down to the kind of level that SCP checks at, so in many ways, I see this kind of feature as indicative of exactly what the SCP is about, providing an engine for modders to create and play their own space-combat games on.
-
To be honest, it's an extremely useful feature in my opinion...
Yes, it is. You can give an estimate on how many windows you may be expecting if/when you actually launch the debug build. Though it would be useful if you could disable it.
-
In fact, aren't you on the team that's supposed to be fixing those errors? :)
In fact, the error message occurs just when I load one of my own mods (StormFront or What If). I don't know what I make wrong to have 71, respectively 143 errors and to be honest, I'm sick of trying to find out. I also can't launch the debug mode, because then this appears:
Warning: Type of weapon SRed entry does not agree with original entry type.
File: Weapons.cpp
Line: 2101
Call stack:
------------------------------------------------------------------
parse_weaponstbl() parse_modular_table() weapon_init() game_init() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c817077()
------------------------------------------------------------------
karajorma once told me that this is some media VP error, so it doesn't look like I could do much about it. ;-)
-
Lets resolve these errors on a separate thread shall we? (hint to admins/mods)
First... that is just an warning, you can ignore it though it might not be wise.
That particular warning seems to be telling that you have defined SRed in Secondary or Beam weapon block of the weapons.tbl though it is in retail and mediavps defined in Primaries block.
What you can do is to run debug and on each and every popup click 'no' then find the 'fs2_open.log' file and post it (via pastebin for example) and then we can have a look at the issues.
-
It would probably be easier to use the keyboard hotkey to do the 'no' clicking, considering just how many he's got.
-
Why can't I just put all the beam guns back into the primaries block of the weapons.tbl? Clicking away the error messages doesn't work anyway, because when the message for the last beam gun has been clicked away, it starts again with SRed.
-
Well yeah, you should do that. But who's to say that's the only unique error?
-
Well yeah, you should do that. But who's to say that's the only unique error?
Oh, it's just that I'm not very motivated to click through some 20 error messages every time I launch FS2. But the 'no' thing doesn't work anyway, see my last post.
-
Well... fix the beams first and then post the next warning the game gives you
-
It would certainly be nice to be able to disable the error message. Most of the errors it picks up are inconsequential so it's mostly an annoyance.
-
Pardon me but I disagree. Those warnings are there to tell you did something stupid. When that happens, you fix it. If you have any pride as a modder, that is exactly what you should do. If you don't, live with it. :p
-
At first I was like :eek2:
then I ran a debug and spend an hour fixing the stupid
Then I was :D
Now I don't get error messages anymore when I load my mod
The new error message at start up is a gift really.
-
Okay, I put all beam guns into the #primary section. The error still occures, but this time I could click them all away. The error message occurs for all beams except BFGreen#8000.
Then this appears:
Warning: For 'Avenger_Impact', 3 of 4 LODs are missing!
File: Weapons.cpp
Line: 1267
Call stack:
------------------------------------------------------------------
parse_weapon() parse_weaponstbl() parse_modular_table() weapon_init() game_init() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c817077()
------------------------------------------------------------------
Then:
Warning: Too many ship classes before 'Asteroid'; maximum is 130, so only the first 130 will be used
Please check also the debug log as it may contain other ship classes which are over the limit
File: Ship.cpp
Line: 3089
Call stack:
------------------------------------------------------------------
parse_shiptbl() ship_init() game_init() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c817077()
------------------------------------------------------------------
Then:
Warning: Unable to find WEAPON_LIST_TYPE string "Targeting Laser"
in ship: GTF Ulysses's primary banks.
File: PARSELO.CPP
Line: 2525
Call stack:
------------------------------------------------------------------
parse_ship_values() parse_ship() parse_shiptbl() parse_modular_table() ship_init() game_init() game_main() WinMain() WinMainCRTStartup() kernel32.dll 7c817077()
------------------------------------------------------------------
Here is a complete list of all errormsgs that appear:
And the *.tbls and *.tbms: Errors_SF12 (http://sebastian.ramrod-network.de/Freespace/Errors_SF12.txt)
ships.tbl (http://sebastian.ramrod-network.de/Freespace/ships.tbl)
1_fs1weapons-shp.tbm (http://sebastian.ramrod-network.de/Freespace/1_fs1weapons-shp.tbm)
1_StormFront12-shp.tbm (http://sebastian.ramrod-network.de/Freespace/1_StormFront12-shp.tbm)
weapons.tbl (http://sebastian.ramrod-network.de/Freespace/weapons.tbl)
0_StormFront12-wep.tbm (http://sebastian.ramrod-network.de/Freespace/0_StormFront12-wep.tbm)
-
a lot of these should speak for themselves
"Warning: Too many ship classes before 'Asteroid'; maximum is 130, so only the first 130 will be used"
Apparantly you went over the ship limit
"Warning: Unable to find WEAPON_LIST_TYPE string "Targeting Laser"
Probably because this "Targeting Laser" isn't listed as a weapon in weapons.tbl
-
All '3 of 4 LODs are missing!' messages... Make sure you have the number of explosion LOD (level of details) defined in the weapon explosions table. As you seem to have just single LOD instead of the default 4.
http://www.hard-light.net/wiki/index.php/Weapon_expl.tbl
All 'Unable to find WEAPON_LIST_TYPE' messages... Make sure there is no excess weapons in the allowed loadout lists for both primaries and secondaries (including dogfight weapons).
The secondary bank of seraphim... Make sure allowed loadout, default loadout as well as capacity and reload time are defined for the secondaries.
'Warning: Bogus string in ship flags: big ship' Hmm.. 'big damage' perhaps?
-
A couple of those look like spelling mistakes ("Mekhu HL7" and "Cluster Bomber"). Also remember that the Seraphim has four secondary banks. If you only want three, I think you need to edit the model.
-
Pardon me but I disagree. Those warnings are there to tell you did something stupid. When that happens, you fix it. If you have any pride as a modder, that is exactly what you should do. If you don't, live with it. :p
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.
-
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.
-
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.
-
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! :)
-
It works... it really works... :eek2: 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.
-
Old player files do not work with Inferno builds.
-
Don't you feel all warm and fuzzy inside now that you got it all working?
-
Don't you feel all warm and fuzzy inside now that you got it all working?
I do. :D But there is still a lot of work ahead.
I made another few changes in the *.tbl and *.tbm and now got this one:
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()
------------------------------------------------------------------
-
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.
-
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.
-
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).
-
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.
-
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.
-
The Lamprey has a "particle spew" flag. Or am I supposed to add the $pspew?
-
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.
-
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. ;)
-
Got this one while playing one of my missions:
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()------------------------------------------------------------------
-
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.
-
That doesn't very serious to me, to be honest. More like some minor .pof problem, maybe?
Here is another one:
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()
------------------------------------------------------------------
-
Hmm... Assuming i'm looking at right spot that is caused by homing weapon trying to home on non-countermeasure and non-bomb weapon.