Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: WMCoolmon on December 18, 2006, 12:22:15 am

Title: Pre-commit build
Post by: WMCoolmon on December 18, 2006, 12:22:15 am
List of changes from current CVS:
Quote
- Added prefixes to some mprintf() calls
- Updated waypoints
- Added bm_is_valid function
- Added cfread_lua_number function
- Added strextcmp
- Removed dependency on any external media files
- Various un/signed casting fixes
- More conditional scripting support
- Better Lua debugging
- Reworked low-level Lua code
- Regrouped Lua libraries, added FS2 filesystem support.
- Animated nebula poofs
- All weapons are checked for collisions, even if nothing is done
- Fixed hud-toggling with freecamera
- Implemented batchers for all particle types
- Added per-shipclass debris settings
- Added fully settable particle emitters for impact and damage spews
- Added $Detonation radius, detonates weapon at X radius from target

Not including changes that I missed in looking over the diffs.

Please test this build. It'll be a lot easier to sort out bugs now, than six months down the line. I'm also looking for feedback on the scripting setup. And, er, any of the other half-dozen addtions. Some of the stuff - like debris speed, and particle spews - I imagine will be handy to quite a few people.

http://fs2source.warpcore.org/exes/latest/C12172006.zip

Code: [Select]
$Impact Spew:
   ;;Used when ship collides with something
   +Texture:  ;;Texture or animated texture for particle
   +Relative Position: ;;Position relative to collision point (vector)
   +Relative Velocity: ;;Velocity relative to ship (vector)
   +Relative Normal: ;;Direction particles are emitted from (vector)
   +Normal Variance: ;;How spread particles are from the center. From 0-2, I think.
   +Min Radius: ;;Smallest particle radius
   +Max Radius: ;;Largest particle radius
   +Min Speed: ;;Slowest particle
   +Max Speed: ;;Fastest particle
   +Min Lifetime: ;;Shortest particle lifetime
   +Max Lifetime: ;;Longest particle lifetime
   +Min Particles: ;;Smallest number of particles to emit
   +Max Particles: ;;Largest number of particles to emit
$Damage Spew:
   ;;Same as impact spew. Used when ship is shot.
$Debris:
   +Min Lifetime: ;;Smallest time that debris will last
   +Max Lifetime: ;;Longest time debris will last
   +Min Speed: ;;Slowest that debris will go
   +Max Speed: ;;Fastest that debris will go
   +Min Rotation Speed: ;;Slowest that debris will spin
   +Max Rotation Speed: ;;Fastest that debris will spin

weapons.tbl
Code: [Select]
$Detonation Range:
$Detonation Radius: ;;Distance from target that weapon will automatically blow up
;;Shockwave stuff

scripting.tbl (*-sct.tbm)
Code: [Select]
#Conditional Hooks
$Mission:
$Ship:
;;...
$On Collide Ship:
$On Collide Asteroid:
;;...

$Shipclass:
;;...
$On HUD Draw:
;;...

;;And so on.
#End

A full list of conditions and actions can be found in scripting.html, which is included in the ZIP and can also be generated for any build with scripting via the -output_scripting command line parameter.
Title: Re: Pre-commit build
Post by: Goober5000 on December 18, 2006, 09:40:09 pm
Quote
- All weapons are checked for collisions, even if nothing is done
Eh?  What exactly does this mean?  Won't it harm optimization? :confused:
Title: Re: Pre-commit build
Post by: taylor on December 18, 2006, 10:28:39 pm
Quote
- Implemented batchers for all particle types
Also be aware, that is something which will have to change later.  I've had new batching and rendering code for particles done for months, but it's not good enough so I never committed it.  That's not to say that you shouldn't commit your change here (might even be helpful for the new code), but don't be surprised if it's all totally ripped out and rewritten in 4-5 months.

In order to blend with all other effects properly, a global batcher with new state switching code needs to be used instead of a particle subystem renderer like what we have now.  This needs to handle all effects: particles, fireballs, weapon effects, thrusters, etc., in a single spot so that everything can be properly sorted, blended, and rendered optimally.  I started something like this a while back, and added OpenGL point sprite support to it for much simplified code and much improved performance, but it will be a while before I get to work on that again.  Plus, I'll need to coordinate with Bobboau on it to make sure that it will actually work like I intended, and so that he approves of it. :)
Title: Re: Pre-commit build
Post by: WMCoolmon on December 19, 2006, 12:14:14 am
Quote
- All weapons are checked for collisions, even if nothing is done
Eh?  What exactly does this mean?  Won't it harm optimization? :confused:

Yes, exactly why I chose to mention it. However, it's difficult to allow people to script in collisions between weapons that aren't even checked for collisions. I am very much against adding in a flag to toggle it, since it would require specialized knowledge to use the hook, that would only serve to later trip people up. So I decided to bite the bullet and see what the effects would be if I removed the laser-skipping restriction altogether; for lasers, it only has to do a check for the radii.

Quote
- Implemented batchers for all particle types
Also be aware, that is something which will have to change later.  I've had new batching and rendering code for particles done for months, but it's not good enough so I never committed it.  That's not to say that you shouldn't commit your change here (might even be helpful for the new code), but don't be surprised if it's all totally ripped out and rewritten in 4-5 months.

In order to blend with all other effects properly, a global batcher with new state switching code needs to be used instead of a particle subystem renderer like what we have now.  This needs to handle all effects: particles, fireballs, weapon effects, thrusters, etc., in a single spot so that everything can be properly sorted, blended, and rendered optimally.  I started something like this a while back, and added OpenGL point sprite support to it for much simplified code and much improved performance, but it will be a while before I get to work on that again.  Plus, I'll need to coordinate with Bobboau on it to make sure that it will actually work like I intended, and so that he approves of it. :)

Doesn't sound like it'll be a problem, but thanks for telling me. :)
Title: Re: Pre-commit build
Post by: bycutza on December 19, 2006, 07:13:48 am
i can't download the file (nor any other file from the server) because my computer doesn't connect to  fs2source.warpcore.org .... i told a friend to connect to it and it still didn't work...
my IP is 85.204.128.61..
any idea why it doesn't work? thank you.
Title: Re: Pre-commit build
Post by: Nuke on December 19, 2006, 12:47:11 pm
does this mean i can use my scripted railgun effect without a massive slowdown?
Title: Re: Pre-commit build
Post by: WMCoolmon on December 19, 2006, 03:02:03 pm
i can't download the file (nor any other file from the server) because my computer doesn't connect to  fs2source.warpcore.org .... i told a friend to connect to it and it still didn't work...
my IP is 85.204.128.61..
any idea why it doesn't work? thank you.


That's odd...perhaps the DNS was changed recently, and it hasn't updated for you. The IP of the warpcore.org server is 82.165.252.33, although that won't get you to the fs2source subdomain.

does this mean i can use my scripted railgun effect without a massive slowdown?

Not knowing anything about it, I can't say.
Title: Re: Pre-commit build
Post by: Bobboau on December 19, 2006, 07:29:13 pm
rather than enableing all colisions, you could always check a colision if either object has a script to run.
Title: Re: Pre-commit build
Post by: bycutza on December 20, 2006, 02:07:04 pm
i can't download the file (nor any other file from the server) because my computer doesn't connect to  fs2source.warpcore.org .... i told a friend to connect to it and it still didn't work...
my IP is 85.204.128.61..
any idea why it doesn't work? thank you.


That's odd...perhaps the DNS was changed recently, and it hasn't updated for you. The IP of the warpcore.org server is 82.165.252.33, although that won't get you to the fs2source subdomain.

do you know any mirrors for downloading the files? (at least the mediavps files)? 10x...

by the way i told another friend to download the file and it worked:) (still quite large to send on messenger)..
my first friend has the same ISP as me (the same gateway, also), while my other friend has another ISP :D

oh and if you're talking about my DNS, there is nothing wrong with the servers :)
Title: Re: Pre-commit build
Post by: WMCoolmon on December 21, 2006, 12:11:16 am
rather than enableing all colisions, you could always check a colision if either object has a script to run.

*sighs* Yeah, that is probably true. Although Conditional Hooks aren't stored directly in the object(s); that would add a lot of complexity. Instead, they're stored in one global array that the conditions are iterated through and checked for.

There's a lot that could be done to optimize them, but each time would make them more difficult to work with (on a lower level) so for now I'm crossing my fingers and hoping it doesn't come back to bite me in the ass soon. If it does, I'm fairly certain that in the end it works out to being more efficient to invoke the interpreter to check whether to execute every hook. (Hopefully around the time that spare CPU time starts getting scarce is when somebody starts looking into multiple cores usage.)

i can't download the file (nor any other file from the server) because my computer doesn't connect to  fs2source.warpcore.org .... i told a friend to connect to it and it still didn't work...
my IP is 85.204.128.61..
any idea why it doesn't work? thank you.


That's odd...perhaps the DNS was changed recently, and it hasn't updated for you. The IP of the warpcore.org server is 82.165.252.33, although that won't get you to the fs2source subdomain.

do you know any mirrors for downloading the files? (at least the mediavps files)? 10x...

by the way i told another friend to download the file and it worked:) (still quite large to send on messenger)..
my first friend has the same ISP as me (the same gateway, also), while my other friend has another ISP :D

oh and if you're talking about my DNS, there is nothing wrong with the servers :)


I never said that there was anything wrong with the servers, just that they may have been out-of-sync.

Regardless, if you can't get your connection working properly, you're probably better off asking in the FSUP forum. Last time I tried to mirror the mediaVPs someplace, I lost my free 1&1 account because the bandwidth usage ballooned. :)
Title: Re: Pre-commit build
Post by: IPAndrews on December 21, 2006, 05:04:04 am
Can I just really, really politely please suggest that you keep a close eye on the effects of this weapon collision change. There are some newer mods and campaigns that put a lot of firepower into the air. I'm working on two of them and I'm also thinking about what is probably your flagship mod/campaign at the moment BTRL. Not a good idea to hit it in favour of a scripting system that few people know how to use (unfortunately).  :nervous: No offence intended guys and esp Goober. We all owe a lot to you guys. Grovel, grovel :).
Title: Re: Pre-commit build
Post by: bycutza on December 21, 2006, 08:25:40 am
ok thanks...i'll ask someone on the official site's forum    ::)
Title: Re: Pre-commit build
Post by: WMCoolmon on December 21, 2006, 01:25:39 pm
ok thanks...i'll ask someone on the official site's forum    ::)

It's not used as much as the FSUP (FreeSpace Upgrade Project) (http://www.hard-light.net/forums/index.php/board,120.0.html) forums. They're the home of discussion for the MediaVPs; this forum is only for discussion of the EXEs.

Can I just really, really politely please suggest that you keep a close eye on the effects of this weapon collision change. There are some newer mods and campaigns that put a lot of firepower into the air. I'm working on two of them and I'm also thinking about what is probably your flagship mod/campaign at the moment BTRL. Not a good idea to hit it in favour of a scripting system that few people know how to use (unfortunately).  :nervous: No offence intended guys and esp Goober. We all owe a lot to you guys. Grovel, grovel :).

Alright, let me take a step back here and make something clear...

I released this build so that people could use it to test things. Ordinarily, I wouldn't mind answering questions and so on about the features. However, I can only really postulate; I have no way of knowing whether or not something is 100% sure going to work on somebody else's system, with their own, different configuration. The best way for them to do that is simply to use the EXE to run whatever it is they want to test. That's a process that will probably take 10 minutes, for the most part, less time than it took to build the EXEs and upload them to an FTP. Certainly less time than it took to code and test the features in the first place.

I'm not even going to try to be responsible for testing every feature on every campaign of every mod. If people are unwilling to spend any time to test this build with their mod, then I won't feel any remorse when they discover, six months down the line, that something in this build is causing their mod fatal problems. I gave them the opportunity to test it, find problems when the code was still fresh in my mind. I really can't do any more than that.

So...warning appreciated, but if I didn't know that in the first place, I wouldn't have bothered to mention that in the initial post.

I can code in the optimization to make people feel better, but at this point, I'm not sure that would serve any real purpose. I've got no definite sign that virtually anybody working on one of the aforementioned other mods and campaigns cares at all about this build. That's not very encouraging. I don't feel like writing features for someone who expects a purely one-way relationship with no communication whatsoever.

EDIT: To answer the other part of your post, for the moment, BTRL doesn't have any official missions completed that are large-scale enough to measure any significant change in the weapons collisions.
Title: Re: Pre-commit build
Post by: karajorma on December 21, 2006, 06:55:29 pm
I usually test stuff after it hits CVS anyway but BtRL has been keeping me extra busy the last couple of weeks.

Biggest problem with testing this build is going to be that due to the scripting changes it's going to complain something chronic about scripting.tbl. I suppose I can disable that for the duration of any test.
Title: Re: Pre-commit build
Post by: Nuke on January 12, 2007, 02:55:06 pm
i finnally have time to play with scripting again. first i was trying to get some old scripts to run in 3.6.9 offitial, some stuff like my lead inticator and hudpong i got working again. but those are already obsolete by this build. so be patient while i re-learn how to use scripting. anyway i managed to get the first few lines of my lead code to work before i come to a prob i dont really understand.

Code: [Select]
player = mn.Ships["Alpha 1"]

if player ~= nil then
target = player.Target
end

if target ~= nil then
if target.Position:getScreenCoords() ~= false then

it gets to about there and gives me this

Could not find index 'Position' in type 'object'
Code: [Select]
------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0

Source: (null)
Short source:
Current line: 0
------------------------------------------------------------------


------------------------------------------------------------------
LUA Stack:
------------------------------------------------------------------

1: Userdata [object]
2: String [Position]
------------------------------------------------------------------

now i know you changed some of the usage and after scanning through the scripting.html and other lua resources im still stumped. seems that a position value does exsist in the object but im not really seeing how to get at it.
Title: Re: Pre-commit build
Post by: WMCoolmon on January 12, 2007, 08:18:36 pm
Well first off, handles should never ever be nil, regardless of whether they're set or not.. This is because the lua interpreter will panic if it tries to index a nil variable; short of recoding the interpreter itself, there's no way to change that. To check if a handle is valid, use the :isValid() function.

However, even in that case, you shouldn't be getting that error. getScreenCoords should fail, but it shouldn't cause an error. That's also a native variable to the object class, so it shouldn't be a problem with inheritance. Have you gotten any other errors for object member variables?
Title: Re: Pre-commit build
Post by: Nuke on January 12, 2007, 10:19:22 pm
first off i think i accidently clipped the first line off that error, first line was:

Could not find index 'Position' in type 'object'

secondly im not getting the thing with the :isValid() function. from what youre telling me, am i correct to assume that i should substitute

Code: [Select]
player = mn.Ships["Alpha 1"]

if player ~= nil then
target = player.Target
end

with

Code: [Select]
player = mn.Ships["Alpha 1"]

if player:isValid() then
target = player.Target
end

well that was enough to get in game. it still crashes, but i only updated 2 lines so far. that might have been the whole thing i was doing wrong. im gonna have to keep debuging the script to see what else is wrong. il get back to you on wether or not something is wrong with the code.

*edit*

ok my scripts working good. only other problem was that i had to change target.Velocity to target.Physics.Velocity. now that i figured this stuff out  i can probibly torture test the scripting system a little better.
Title: Re: Pre-commit build
Post by: WMCoolmon on January 12, 2007, 10:25:33 pm
Yeah, that's correct. :) It will also make sure that the ship hasn't died or departed, basically it's a safe-function that should tell you if anything's wrong with modifying the object's variables.

Although as I've said before, things in scripting shouldn't just _crash_. They should give you some kind of error message. If they don't, it's a bug. Debugging is already enough of a pain with the inadequate Lua debug tools...
Title: Re: Pre-commit build
Post by: Nuke on January 12, 2007, 11:15:05 pm
ok one more thing, when i try to use +override: true on the hud, i get this

Code: [Select]
Error parsing HUD override

------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0

Source: (null)
Short source:
Current line: 0
------------------------------------------------------------------


------------------------------------------------------------------
LUA Stack:
------------------------------------------------------------------

1: Userdata [Audio]
2: Userdata [Base]
3: Userdata [Controls]
4: Userdata [Graphics]
5: Userdata [CFile]
6: Userdata [Mission]
7: Userdata [ScriptingVariables]
8: Userdata [Tables]
9: Userdata [Testing]
10: Function
------------------------------------------------------------------

however if i click no it goes back to the game and runs without a hitch. is this a bug ore does it indicate a case of bad scripting :D
Title: Re: Pre-commit build
Post by: WMCoolmon on January 13, 2007, 03:32:12 am
Well, as near as I can tell from testing, this is the result of some stupid Lua move whereby the "return" statement no longer works as it used to. Because I was using it for the +Override: statements, they're pretty much disabled right now. That is something I can hack together a fix for easily enough.

I think. (Crosses fingers)
Title: Re: Pre-commit build
Post by: Nuke on January 13, 2007, 02:34:00 pm
i made something cool -> http://www.hard-light.net/forums/index.php/topic,44634.0.html

*edit*

might want to look at that thread, me and wanderer are finding bugs.
Title: Re: Pre-commit build
Post by: WMCoolmon on January 19, 2007, 10:52:41 pm
http://www.hard-light.net/forums/index.php/topic,34786.0.html

There's no way I can deal with bugs efficiently in a development thread for a script.
Title: Re: Pre-commit build
Post by: Nuke on January 21, 2007, 04:22:19 am
so noted, i put a couple up on mantis for now. il have to make a not to do so every time something doesnt work.
Title: Re: Pre-commit build
Post by: Turambar on January 22, 2007, 06:21:05 pm
- Animated nebula poofs

nifty, cant wait to see what we can do with that
Title: Re: Pre-commit build
Post by: Gregster2k on January 24, 2007, 02:20:14 pm
Can we make the nebulae look exactly like they did in the Bosch cutscenes yet? :3
Title: Re: Pre-commit build
Post by: Vretsu on April 11, 2007, 08:23:43 pm
List of changes from current CVS:

- Updated waypoints
- Added bm_is_valid function
- Added cfread_lua_number function
- Added strextcmp
- Removed dependency on any external media files
- Various un/signed casting fixes
- More conditional scripting support
- Better Lua debugging
- Reworked low-level Lua code
- Regrouped Lua libraries, added FS2 filesystem support.

 ---> - Animated nebula poofs <---

- All weapons are checked for collisions, even if nothing is done
- Fixed hud-toggling with freecamera
- Implemented batchers for all particle types
- Added per-shipclass debris settings
- Added fully settable particle emitters for impact and damage spews
- Added $Detonation radius, detonates weapon at X radius from target

Animated...nebula poofs.

The revolution is here. Someone find Lightspeed. >.>
Title: Re: Pre-commit build
Post by: takashi on April 22, 2007, 12:29:09 pm
hm...debris settings in tablse do nothingmfor me. same, slow, floating spacejunk. no 400 mps debris :\
Title: Re: Pre-commit build
Post by: WMCoolmon on April 29, 2007, 04:44:17 am
Can you upload the table you're testing with?
Title: Re: Pre-commit build
Post by: shiv on May 06, 2007, 02:41:02 am
Okay... as some of you know, I'm making my own total conversion for FreeSpace. I'm going to use this build, because I like option Impact Spew, but I still don't know is this build stable?? When I'll see "impact spew" in every build?
Title: Re: Pre-commit build
Post by: WMCoolmon on May 06, 2007, 03:08:53 am
I don't know. Finals are coming up and I've had other priorities recently, so my codebase is undoubtedly out-of-date with what's in CVS. So I don't know if I'll just have to fix the current crash problems, update it to CVS, and then commit it, or do something more intensive in order to update the CVS HEAD tree.
Title: Re: Pre-commit build
Post by: shiv on May 06, 2007, 03:14:21 am
I've just tried "impact spew", but the game crashes. I mean I've got weapons.tbl bug after clicking "run" in launcher.
Title: Re: Pre-commit build
Post by: WMCoolmon on May 06, 2007, 03:26:02 am
I've just tried "impact spew", but the game crashes. I mean I've got weapons.tbl bug after clicking "run" in launcher.

Alright then. Now I ask you: how do you possibly think I could offer anything useful from just knowing that there's some error that's related to some file, when I don't even know what the error says or what's in the file?
Title: Re: Pre-commit build
Post by: shiv on May 06, 2007, 06:08:04 am
Here's the error:

Code: [Select]
---------------------------
Error!
---------------------------
Error: weapons.tbl(line 1469:
Error: Required token = [#End] or [$Name:], found [$Impact Spew:]
in weapon: @GEM-176 Shark.


File:\Documents and Settings\Administrator\My Documents\My Source Code\fs2_open\code\parse\parselo.cpp

Line: 673

[This filename points to the location of a file on the computer that built this executable]



Call stack:

------------------------------------------------------------------

------------------------------------------------------------------



[ This info is in the clipboard so you can paste it somewhere now ]





Use Ok to break into Debugger, Cancel exits.


---------------------------
OK   Anuluj   
---------------------------

If you need more info, here's my weapon table:

Code: [Select]
$Name:                                 @GEM-176 Shark
+Title:                                XSTR("GEM-176 Shark", -1)
+Description:
XSTR(
"Standard Issue
Swarm Type
All-Purpose Missile", 3326)
$end_multi_text
+Tech Title:    XSTR("GEM-176 Shark",-1)
+Tech Anim:    none
+Tech Description:
XSTR(
"Shark missiles are standard weapon in every hangar. Before you fire it's needed to lock it.", -1)
$end_multi_text
$Model File: missile1.pof
$Mass: 0.1
$Velocity: 190.0
$Fire Wait: 1.0
$Damage: 25.0                                      ;;

damage applied when within inner radius
$Blast Force: 0.2
$Inner Radius: 10.0

;; radius at which damage is full (0 for impact only)
$Outer Radius: 20.0

;; max radius for attenuated damage (0 for impact only)
$Shockwave Speed: 0                                         ;;

velocity of shockwave.  0 for none.
$Armor Factor: 1.5
$Shield Factor: 0.7
$Subsystem Factor: 0.1
$Lifetime: 10.0
$Energy Consumed: 0.0

;; Energy used when fired
$Cargo Size: 0.5

;; Amount of space taken up in weapon cargo
$Homing: YES
;; the following indented fields are only required when $Homing is YES
+Type: ASPECT

;; Legal: HEAT, ASPECT
+Turn Time: 1.15
+Min Lock Time: 2.5

;; Minimum lock time (in seconds)
+Lock Pixels/Sec: 60                                        ;; Pixels

moved per sec while locking
+Catch-up Pixels/Sec: 100

;; Pixels moved per sec while catching up
+Catch-up Penalty: 30

;; Extra pixels to move after catching up
$Swarm: 6
$LaunchSnd: 89                                       ;;

The sound it makes when fired
$ImpactSnd: 88                                        ;;

The sound it makes when it hits something
$FlyBySnd: -1
$Rearm Rate: 1.0

;; number of missiles/sec that are rearmed
$Flags: ( "in tech database" "player allowed"

"particle spew")                   ;;     
$Trail: ;; Trail cannot be

set if Exhaust is set
+Start Width:          0.25                                      ;; Width of trail

nearest missile
+End Width:            0.5                                       ;; Width of trail

before it "evaporates"
+Start Alpha:         1.0
+End Alpha: 0.0
+Max Life: 2.5                                       ;;

how many seconds before trail disappears
+Bitmap: trail1

;; Bitmap used to draw trail
$Icon: iconHornet
$Anim: hornet
$Impact Explosion: explo3
$Impact Explosion Radius: 5.0
$Impact Spew:
   ;;Used when ship collides with something
   +Texture: ParticleSmoke02  ;;Texture or animated texture for particle
   +Relative Position: 30 ;;Position relative to collision point (vector)
   +Relative Velocity: 30 ;;Velocity relative to ship (vector)
   +Relative Normal: 30 ;;Direction particles are emitted from (vector)
   +Normal Variance: 2 ;;How spread particles are from the center. From 0-2, I think.
   +Min Radius: 10 ;;Smallest particle radius
   +Max Radius: 50 ;;Largest particle radius
   +Min Speed: 40 ;;Slowest particle
   +Max Speed: 80 ;;Fastest particle
   +Min Lifetime: 5 ;;Shortest particle lifetime
   +Max Lifetime: 10 ;;Longest particle lifetime
   +Min Particles: 5 ;;Smallest number of particles to emit
   +Max Particles: 15 ;;Largest number of particles to emit
Title: Re: Pre-commit build
Post by: Wanderer on May 07, 2007, 12:58:43 am
AFAIK...

Impact spews and other such are placed to ships.tbl not to weapons.tbl (unless this has been changed) and also they have to be placed into their proper place in table (ie. where the parser expects them). Which at least with older impact and damage spews was between $Show damage: and $Density: entries.