Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
I warned you...
Annotated template: The wëap resource
The wëap resource stores the weapon information for the weapon outfits, and only this information: there still needs to be a corresponding oütf resource for the other information such as availability, and maybe another outfit for the ammunition, if applicable. Notice that even if you don't intend your weapon to be available in outfitters, you should still create a corresponding outfit that grants it, unless you don't intend the player to have it. Indeed, if the player owns a weapon for which there is no outfit that grants it (the player obtained the weapon as a default weapon of his new ship, for instance), it will be removed as soon as the player lands.
First off, the name of the resource itself is used for the weapon name shown in the interface side bar when you select it as a secondary weapon, so you can't use it as you wish, unless you don't intend your weapon to be used by the player or it's a primary weapon; keep it short, also. However, you can put a semicolon and text after it in the resource name, they will be ignored, effectively allowing you comments, such as "Hector Cannon; anti-Charlie version".
The Reload field This number field holds the minimum amount of time between two shots of the weapon, in frames (that are 1/30th of second), which dictates its rate of fire when the weapon is fired continuously. The frame is the base unit of time in Nova, so get used to it now. Notice that firing a shot already takes one frame by itself, so 0 is a perfectly valid value, there will just be no reload interval and one shot every frame (30 a second). If 1, there will be one frame for firing the shot, then one frame for reload, then the weapon will fire again, so there will be one shot every other frame (15 a second). If 2, one shot every 3 frames (10 a second). Etc: if n, one shot every n+1 frames (30/(n+1) a second), which is not really different from n when n is big.
This is for the case when the ship owns only one (no more) instance of this weapon. If the ship owns more than one launcher (say m), shots are fired one by one, but every (n+1)/m frames, with an important limitation: there can't be more than one shot per frame, regardless of the number of launchers. This means a weapon with a Reload of 0 already fires as fast as it can when the player owns one, so there is really no point in owning a second launcher. A weapon that has a Reload of 1 will already fire every frame when the ship owns 2 of it ( (n+1)/m=(1+1)/2=1 ), so the player won't benefit from owning any more launchers, as no more than a shot can be fired per frame, and he already fires one a frame with two, so he will still fire one shot a frame with 3, 4, or more launchers. Same thing is Reload is 2, 3, etc: owning more than Reload+1 instances of the weapons is useless to the player. As a consequence, adjust the "Max" field of the oütf resource matching the launcher to Reload+1 or less, so that the player does not buy more launchers than what's actually useful. This is true for beams as well: even if they don't have "shots" so to speak, they still can't "fire" more than once per frame, and since their damage is applied differently, you might as well give an important value (say 20-30) here and in the Count field.
There are two exceptions to the limitation above. First, if the weapon has the "fire simultaneously" flag set, then m shots will be fired together (in the same frame) every n+1 frames, so having m launchers is always m times as efficient as owning one. Second, if the weapon has a burst reload, then the player can always benefit from owning more launchers as even if the firing rate does not increase, he will be able to fire more shots before having to endure a burst reload (whose length is constant), which is good overall (though not m times as efficient); a good example is the chaingun cannon, experiment with it.
At any rate, don't be afraid by these problems, experiment to find the most sensible value for now.
The Count field This number field holds the lifetime of the shots of the weapon, in number of frames. This means you divide it by 30 to abtain the life of one shot in seconds. In effect, it states the range of your weapon: the range, in pixels, is the value in this field times the value in the Speed field, divided by 100; to give you an idea, the playfield when playing in 800x600 is around 600 pixels wide and high. Then again, start with a sensible value, then experiment. In case the the weapon is a beam (depends on its guidance), this will instead be the number of frames the beam stays on screen. As a consequence, it should probably be set to the same as reload, unless you want to give the impression the beam has misfires (if you put less) or to have too many beams on screen (if you put more): remember there can only be a maximum of 64 beams on screen at the same time.
The MassDmg field If and when a shot of this weapon hits a ship with its shields knocked down, this number field holds the amount of damage done to the armor of the ship. The total armor of the ship is the value in the shďp's Armor field. You can tell the amount of damage done by second of the weapon to armor, provided all shots hit, is the value in this field divided by the value in the Reload field, plus one, and multiplied by 30. Then again, you should check what the other similar weapons does, and experiment to find what's best. Notice that's also that amount of damage done to an asteroid should the shots hit one.
The EnergyDmg field If and when a shot of this weapon hits a ship with shields still up, this number field holds the amount of damage done to the shields of the ship. The total amount of shielding is the value in the shďp's Shield field. You can tell the amount of damage done by second of the weapon to shields, provided all shots hit, is the value in this field divided by the value in the Reload field, plus one, and multiplied by 30. Then again, you should check what the other, similar weapons does, and experiment to find what's best. This is completely ignored against 'roids. Notice either of those two fields can be set to 0 for no corresponding damage: the TripHammer does no shield damage at all, for instance. Notice damage is applied differently for beams: while non-beam weapons apply their damage once per shot, MassDmg/EnergyDmg is applied every frame the beam hits the target ship. This means that these two fields are usually set to lower values than for other kind of weapons, and changing the Reload/Count pair won't change the damage.
The Guidance field One of the most important field of the wëap resource, this number field tells how the weapon shots will (attempt to) go to their aim (or miss it), in effect specifying the kind of weapon: whether it's a gun, a missile weapon, a point defense weapon, etc. There are only 12 significant values, so this is probably a popup menu in your editor. "unguided": -1 makes the weapon shots will be completely unguided. They will exit at a random angle in the inaccuracy range, and go straight at maximum velocity. Weapons with this guidance are the normal guns such as the blasters, and are usually made to take up one fixed gun slot (this is specified in the corresponding outfit). "beam": 0, there won't be shots, the weapon will be a beam, with all the modifications that apply (for instance everything that refers to the weapon graphic will be ignored, I won't tell it every time). This kind of beam is the default, unguided straight one, in a random direction in the inaccuracy range. Weapons with this guidance are thought of as another kind of gun (like the Pulse Laser) and usually also take up one fixed gun slot, and they sometimes draw fuel. "homing": 1, the weapon shots will exit in the inaccuracy range around the front direction, but will home to their target afterwards; a target is required for this weapon to fire, as a consequence. The exact details of the homing efficiency are set in some fields next. Such weapons are thought of as missiles, torpedoes or homing rockets, like the Radar and IR missiles and the EMP Torpedoes, and usually draw ammunition. 2 is unused for historical reasons (in EVC it stood for dumb homing, like a torpedo, the previous one being smart homing) "turreted beam": 3, there won't be shots, the weapon will be a beam, with everything that applies. This kind of beam is turreted, firing to the direction the target is (maybe with some inaccuracy); a target is required for this weapon to fire, as a consequence. This is seen as a different, maybe more accurate (as beams are instantaneous) and technologically advanced kind of turret, such as the Ion Cannon and Turreted Pulse Laser, that takes up one turret slot. "turreted": 4, The shots will fire to the direction the target is (maybe with some inaccuracy), but will be unguided and go straight afterwards. Such weapons are the turrets in the game, like the blaster turrets, and usually take one turret slot. "freefall": 5, this will be something like a space bomb or mine, that is just detached from the ship when fired; it will go at 80% of the speed of the ship in the same direction and continue that way. These are usually big ammo using weapons that deal a lot of damage... if they happen to hit something. This guidance is almost unused in the default Nova scenario, just for some weapons only used by stations. However, you can check the Space Bombs of the EV Classic total conversion for an example. "freeflight": 6, this is a variation on unguided, the difference being the shots will start at a small velocity and then accelerate to the maximum speed; it makes more sense for unguided rockets and the such and allow more time for you to react to these weapons. The Raven Rocket is one of these. "front-quadrant turret": 7, same as turreted but only in the range from 45° (1/8 of a turn) to the left of the straight ahead direction to 45° to the right (1/4th of a turn total); this is often referred to as the front quadrant. It will fire straight ahead if there is no target or if it can't be reached within the turning range. This is mostly used for swivel cannons that attempt to track the target to some degree, like the Fusion Pulse Cannon, or conversely for primitive turrets that can't target out of this range. 8: "rear-quadrant turret", same as above but around the straight back direction; also, it won't fire if there is no target or if target is not in the turning range. This is here for some gimmick weapons that fires to your pursuers, but isn't really an useful or main combat weapon. This guidance is completely unused in the stock Nova scenario, but you can check the rear phase cannon, of the EV Override total conversion, for an example of such a weapon. 9: "point defense turret", this automatic turret will fire to weapon shots and ships that are marked as can be targeted by point defense (most missiles and most fighters are, respectively), attempting to destroy them before they can harm the ship it is on. You can't direct them, they are entirely automatic; the quad light blaster turret is one of these. You should give some inaccuracy and/or burst reload and/or make it not powerful so as not to make the ship owning it overprotected. 10: "point defense beam", this automatic turreted beam will fire to shots and ships that are marked as can be targeted by point defense (most missiles and most fighters are, respectively), attempting to destroy them before they can harm the ship it is on. You can't direct them, they are entirely automatic; this guidance is considered overpowered compared to the latter, especially since beams are instantaneous (even fast missiles will be hit) and do not suffer from any inaccuracy, so give some burst reload and/or make it not powerful so as not to make the ship owning it invincible. Notice this guidance is completely unused in the default Nova scenario. 99: "carried ship", this one behaves differently from all others, almost all fields are ignored and the ship owning this weapon will launch another ship (usually a fighter) when triggering this weapon; the ID of the ship class launched should be entered in the AmmoType field. The weapon is in effect a fighter bay, just like the Viper, Thunderhead, Phoenix, Manta, etc... bays.
The Speed field This number field holds the speed of the weapon shots, which is technically in pixels per frames, times 100. Then again, put a sensible value from an outfit similar to the one you wish to make, then test and adjust to find what's best. Notice that a weapon shot will be drawn on screen only once per frame, so if the speed is too fast the shots drawn will be too much spaced. You can very well put a 0 speed for a weapon that will stay put after being launched. This is ignored for beam weapons, but considered for fighters, this is the speed they will exit the mother ship at.
The AmmoType field This number field specifies from which weapon this weapon should draw its ammunition; it can be a popup menu with a field in your editor. It may seem trivial it should draw ammo from its own ammunition stock, but by putting the index of another weapon you can tell more than one weapon to use the same ammunition, such as is done with Wraithiis or chaingun ammo in the default Nova scenario, just remember to do only one ammunition outfit, that references the ID of the common weapon from which ammo is being drawn. There is a caveat to this, that if a ship come with default weapons that use the same ammo as another weapon that also comes with the ship, you should specify the amount of ammunition only in one of the two and leave the other ammunition amount to 0. You can put the following there
"no ammo": -1 will make the weapon not use any ammunition and be able to be fired at will without worrying about depleting anything, like a Blaster or Fusion Pulse Cannon.
"from this weap index": Putting a value between 0 and 255 will make this weapon draw ammo from the stock of the weapon at the index indicated. Usually for an ammo-using weapon you will set it to the index of the wëap resource this field is in, like in IR and Radar missile weapons. * But you can tell a group of weapons to use a common ammunition by having one main weapon (that can be any of the group) draw ammo from itself, and the others have the same value as the main one in their AmmoType field; see the aforementioned examples for more info.
"draw fuel": Putting a value below -1000 will make the each weapon shot draw a certain amount of fuel (or energy), technically the absolute difference between the value and -1000 divided by 10, units of fuel; remember an hyper space jump draws 100 units of fuel. If you want each shot to draw one unit of fuel, put -1010. If you want each shot to draw one hyperspace jump worth of fuel, put -2000. You should then again experiment to find the best value to give (check weapons such as the Vell-Os ones). Notice that for developing purposes the plug devers often talk of fuel for the hyperspace propeller and not of energy for historical reasons (in EVC and EVO it was fuel, it's shorter to write, the Bible uses "fuel", etc...)
"destroy ship on fire": -999 will make the firing ship explode when attempting to fire the weapon, as simple as that. RIP. Unused in the stock Nova scenario.
Notice beams cannot use ammunition other than fuel. Also, if the guidance is 99 (i.e. the weapon is a fighter bay), the weapon always uses ammunition and this field instead tells the ID of the shďp resource to use for the fighter.
The Graphic field This number field is used to know which shot graphic to use for this weapon: you should put a value between 0 and 255 for the weapon shots to use spďn ID 3000 + the value. This can make sense instead of hard-linking the spďn to the wëap (like is done with shän to shďp), for instance for the Hector Turret to use the same Hector Birdseed Pellet shot as the Hector Cannon. Notice this part of the Bible is outdated (it tells to put a value between 0 and 63 to use spďn ID 200-263), the good info can be found at the spďn section. As a general rule, if there seems to be some discrepancy in the Bible, assume the bigger unless you see evidence against it, as the bigger has probably been put later, and maybe some parts have been mistakenly not updated. This field is ignored for beam weapons, as is everything that has to do with the shot graphic (however, negative values used to be used to give the beam color; though this has been superceded by the BeamColor field, there still are some -x values leftover in beam weapons of the default Nova scenario).
The Inaccuracy field This number field holds the amount of inaccuracy of the weapon shots in degrees to the left and the right to the desired direction of fire. For instance a value of 5 for a gun will make the shots go haphazardly in a 10 degree cone (5° left to 5° right, i.e. 1/36th of the full circle) in front of the ship. This means that 0 will make the weapon perfectly accurate (at least fire straight up/where the turret computer sets it to go, it can still miss), an higher value a weapon not perfectly accurate, the more is there is the less accurate the weapon will be (for instance the Storm Chaingun with a 20 inaccuracy is quite inaccurate), up to 180 where the weapon will fire in a completely random direction (this is the case for Nanites). You should put a sensible value then adjust after testing, as with many other things in weapons. Notice this is ignored for PD beams, making them all the more overpowered. A previously undocumented goodie, that Matt Burch revealed afterwards to the community: if you put a negative value there, the shots will exit EXACTLY at the two angles that would have been the limit if the opposite positive value had been put. For instance, putting -90 for a gun will make shots exit at the two sides. It works at least for Unguided, Turreted Unguided, and the Front and Rear Turrets (guidances -1, 4, 7, 8).
The Sound field This number fields stores which sound to play when the weapon is fired: a value between 0 and 63 will make the game use the sound found at the 'snd ' resource ID 200+value (between 200 and 263). It's considered bad not to put any sound for a weapon as the player won't be able to know a weapon has been fired to him or his weapon has succesfully fired, unless you wish the weapon to be especially dangerous for this former reason, put then -1 for no sound. Even for developing purposes you should put a placeholder sound.
The Impact field This number field states how much the ship recieving the weapon will be pushed by the explosion: -1 will work only for beams and make it a tractor beam, such as the ones in the EV and EVO games and TCs. The lighter of the two ships (be it the firing or recieving ship) will follow the movements of the bigger ship as long as the beam is being fired, and a ship that's under the effect of the tractor beam of a bigger ship won't be able to hyperspace (Star Wars, anyone?). However, inertialess ships are differently affected. 0 will make the weapon not have any impact at all (this is pretty rare in the default Nova scenario, only the nanites do)
0 will make the weapon impact push the ships around it by an amount proportional to the value entered, inversely proportional to the ship's mass (bigger ships are less moved), amount that goes down with the distance between the affected ship and the explosion. As usual, put a sensible value first then experiment. Notice it's the impact per shot/beam unit received, this makes the Thunderhead Lance have quite an impact, but since it's a beam a special rule (similar to the behavior of tractor beams) applies: if the firing ship is lighter than the receiving ship, the firing ship is repulsed instead. The railguns have quite an impact as well.
The ExplodType field This number field states which kind of explosion the weapon shots will make when hitting a ship. This now comes down to telling which bööm resource to use: "no explosion": -1 will make no explosion "simple explosion": A value between 0 and 63 will make the game display an explosion following the bööm resource at index the value (i.e. ID 128+the value) "complex explosion": A value between 1000 and 1063 will make the game use bööm idx 0-63, plus a random number of 0-kind explosions (the basic kind) around it (usually put for big explosions, like for the HellHound missile).
The ProxRadius field This number field tells how close from a target the shots have to be for it to explode: 0 will make the weapon require direct hit to impact, while a value >0 will make the weapon explode when it reaches a distance equal to the value in pixels of the target. The bigger you put, the farther from the target it will explode. You should experiment to find your value. This is best used for missiles, rockets, and especially bombs that may otherwise miss their target. This is ignored for beam weapons (though it used to tell the beam width, this is now deprecated due to the BeamWidth field but there still are some values leftover in the default Nova scenario).
The BlastRadius field This number field tells how far from the point it hits the weapon will deal damage. 0 will make no such blast damage, while more will deal damage in a range in pixels of the value entered. It's probably best to put a value above or equal to the one in the above field. Then again it makes the most sense for missiles, rockets and bombs. This is ignored for beam weapons.
The Flags field Here are set a number of specific options for the weapon. If there no example from the default Nova scenario given for a flag (including a seeker flag), this means there is none at all and the flag is unused in the stock Nova scenario.
"spin instead of rotating" will make the weapon shot animated (but as a trade-off, rotation won't be seen): the frames will spin continuously, like is done in the fusion pulse weapons. Obviously, you will have to make weapon shots sprites adapted for this behavior. The default behavior being obviously to have each frame match a direction for the weapon shot.
"secondary weapon" will make the weapon have to be chosen between the other secondary weapons, and fired by the secondary fire key (default: ctrl). The default behavior is obviously to have the weapon be fired at the same time as all other primary weapons when firing the primary fire key (default: space). This should be set if your weapon draws ammunition or fuel or is not to be fired when the player does not specifically wants this weapon to be fired for any other reason.
"start animation on first frame": if the first flag has been set, the graphic cycling will always start on the first frame of the Rle/PICT. This can make more sense (especially with "keep first frame until..." below) if the first frame is the weapon shot as it exits the tube.
"don't fire at fast ships" will tell the game that, this weapon being some not-very-accurate weapon (like a cludgy torpedo), the AI ships won't attempt to fire it at fast ships, that are defined as the ships having a turning speed >30 (which is like 90° per second). The player is free to do as he wants, though.
"sound looped rather than repeated" will make the firing sound be looped as long as the weapon is fired, then stopped when the player stops firing, rather than restarted each time a new shot is fired. This is easier experimented that explained: use it to hear the difference; especially, it makes more sense for beam weapons. In fact, it's mainly set for these weapons in the default Nova scenario.
"shield penetrating" will make the weapon ignore any shielding the ship may have and directly damage armor. This makes the weapon an especially dangerous one, so don't overuse unless you wish to render any shielding technology useless. For this reason, only the nanites, the Winter Tempest and the TripHammer have this ability in the default Nova scenario.
"fire simultaneously": if a ship owns more than one instance of this weapon and fires it, it will fire n shots at once (n being the number of launchers owned) but reload time will be unaffected by the number owned. The default behavior is for one shot to be fired at once, but the weapon to reload n times faster (the launchers fire one after another in sequence); this makes for the same number of shots overall but may make missiles launched in salvoes more dangerous (but see the Reload field). This is just used in the Firebird and Phoenix bays in the default Nova scenario.
"can't be targeted by point defense" will make the weapon shots untargetable by point defense systems, that won't fire at this weapon. Notice that point defense weapons fire only at homing weapons (guidance 1), so this isn't useful for the other weapon types. Most Polaris missiles are blessed with this ability.
"blast doesn't hurt" will make the weapon blast, if any, not damage the launching ship even if it's in the blast radius; this can be a feature of a weapon designed to be operated at short range. The EMP Torpedoes, Hellhound missiles but also the mining lasers have this feature, for instance.
... wait, no other flag?! yehee! Err, oops, here come the seeker flags.
The Seeker flags These control some behaviors of homing weapons:
"passes over 'roids" makes the weapon pass over asteroids as if they didn't exist (in fact, it's usually considered it avoids them as ships do). This makes the weapon especially dangerous and surprising in asteroids-infested systems, so don't overuse. This is set for Polaris Etheric Wake missiles, Torpedoes, for instance. (this flag also works for non-homing weapons)
"decoyed by 'roids" makes the weapon be attracted by asteroids when passing near them. It makes the weapon pretty unuseful in systems infested by asteroids. I don't think it's a good idea to combine with the latter. Such stupid weapons are the IR missiles ('roids are hot?!), radar missiles and gravimetric missiles.
"confused by interference" makes the weapon guidance systems be affected by sensor interference, more affected if there is more interference, up to being completely useless when there is really heavy interference. Weapons thus affected are the radar missiles and other such radar-guided missiles (EMP torps, Hellhound) but also the Etheric Wake missiles.
"turns away if jammed" will make the weapon be completely repulsed by the target if it jams it, instead of just going at random.
"can't fire if ship is ionised" makes the weapon unable to be fired (for whatever reason you care to give) if the firing ship is ionised (this is in the seeker flags for complex reasons, it applies to all weapons in fact).
"loses lock if target not ahead" makes the weapon guidance be a pretty primitive one (like the kind of laser guidance that's in use in some guided weapons of today's warfare) that's only able to follow the target if it remains around the front of the weapon. It makes sense to have this guidance for a powerful, nearly unguided rocket, that just has this guidance so as not to waste one if the target moves a bit.
"may attack firing ship if jammed": if the guidance system is jammed by the target, not even the firing ship is safe from being hit by the jammed, erratic missile.
The SmokeSet field This number field states which smoke icons to use for weapons that leave a smoke trail. If 0 is put, the engine will uses cicn ID 1000 to 1007. If 1 is put, cicn ID 1008-1015, etc: if n is put, cicn ID 1000+8xn to 1000+8xn+7. However, be careful that the smoke feature is completely unused in the default Nova scenario; if you wish to use it, you'd better make your own smoke sprites or salvage them from EVO (don't quote me on this nor tell that I told you to) as you won't find any smoke icon anywhere in the Nova Data files. Put 0 if you don't use.
The Decay field If the weapon is not a beam, this number field tells how fast the shot power will decrease over the time elapsing after it is launched: one point of mass damage and one point of energy damage will be removed after each n frames, n being the value put in this field; the bigger you put, the slower the decay will be. For instance, 30 will make one point of damage go away every second, 60 every two seconds, 10 three times a second. Depending on the total damage of one shot, it can be big. Experiment again to find the value that will match the behavior you wish (check first weapons that use this feature such as Railguns or Fusion Pulse weaponry). Think to leave some power remaining for the shot at the end of its lifetime. Leave to 0 or -1 if you don't use. If the weapon is a beam, putting a value greater than 0 will make the beam corona shrink when disappearing; this is the case for the Pulse Laser and Vell-Os weapons. You should pay attention to the fact that, in that case, the actual time the beam will stay onscreen is Count + 16 - Falloff, so you should adjust Count so that the result of the previous expression matches the Reload value so as not to have more than one beam on screen at the same time. See Guy's research below for more info. Leave 0 for the beam to act as usual.
The Particles field This number field stores the amount of particles the shot will produce each frame (a frame being one/30th a second, as always) in random directions. Multiply by 30 for the number of particles a second; put more for more particles. Most Nova weapons use this feature. 0 for no particle.
The PartVel field If the shot produces particles, this is the speed of the generated particles; significant values are comprised between "1 to about 200 or so. Experiment to find useful values" (straight from the Bible). I can't give you much more, other than entering a very little speed will make the particles remain in the weapon trail and give the impression the shot leaves smoke, or anything else.
The PartLifeMin field This is the minimum life expectancy of a particle, in number of frames; 30 will make the particles live at least one second, more will make longer-living particles. Depending on the speed of the weapon shot, this will make a more or less long "particle trail".
The PartLifeMax field This is the maximum life expactancy of a particle, in number of frames; 30 will make the particles live at most one second, more will make longer-living particles. Put a value superior to the one found in the above field, obviously.
The PartColor field This hex field, that's probably implemented as a color picker in your editor, allows you to choose the color the generated particles will be. If there is an hex field, it's encoded the same as an HTML color (first two hex numbers unused if there are eight, then each following pair being one color channel, first Red, Green, then Blue), use some tool that will give you the HTML color from a color picker to know what to enter here.
The BeamLength field If the weapon is a beam, this number field tells the length of the created beam, probably in pixels (but don't quote me on this), experiment as usual to have the beam be the length you wish. If the weapon is not a beam, putting a positive (non-zero) value will make the shot graphic fade out instantly around one second before the end of count; this is both undocumented and unused in the default Nova scenario but has been discovered by chance by Edwards.
The following information about beams has been investigated and documented by Guy (yes, Guy). In fact, he already put it very well:
Guy, on Jan 14 2005, 09:02 AM, said:
"BeamWidth: For straight beams (non-lightning beams) the BeamWidth field doesn't really describe the beam's width at all. The width of the beam core is preset and is about 3 pixels. The width field instead describes the distance between the two sides of the corona. This can cause beams to look slightly odd if set to 3 or more as the corona appears detached from the beam core. (eg. Autumn Petal, Solar Lance). Note that the corona is not the bit that does the damage - objects will pass straight through the corona and not take damage until they hit the beam core. The picture shows a modified CPL with a BeamWidth of 8. attachment
Falloff: This is basically the width of the corona. A value of 1 is the widest (even though the bible says it should be 2-16) and the corona seems to get exponentially thinner as the falloff increases, up until 16 which is the same as a value of 0 (the corona will always be at least 1 pixel wide though). The picture shows the same beam as above with a Falloff of 1. attachment
Decay: As the bible describes, if this is greater than zero the beam will "shrink" before it disappears from the screen. Higher values make no difference. What the bible doesn't say is that it is actually the corona that shrinks, so there must also be a positive falloff value for this to work. The wider the corona (the lower the falloff), the longer it takes to shrink. The actual time the beam spends on screen will be Count+16-Falloff.
One interesting thing you can do with straight beams is give them a negative width. This causes the two sides of the corona to shift in the opposite direction and can create a cool effect if you have a low falloff. The picture shows the CPL with a BeamWidth of -6 and a Falloff of 2. attachment Lightning Beams
BeamWidth: For lightning beams the BeamWidth really is the width of the beam. Lightning beams do not have a separate corona (Falloff and CoronaColor fields are ignored) but instead have their own natural corona. However, if the width is 32 or greater it will lose its natural corona and will just be a solid color. Whatever the width though, the damage is still only done down the very center of the beam - even sharp jags sticking out are harmless. The picture shows the CPL with a LiDensity of 3 and a BeamWidth of 16. attachment
Decay: A value of 1 here will cause the whole beam to shrink before it disappears, unless the width is 32 or greater in which case it will simply fade out. The time the beam spends on screen is about Count+16.
Thanks to Guy for allowing me to quote him and for documenting that in the first place.
Some other things about these fields, though: if the weapon is not a beam and the first flag is set ("spin instead of rotating"), the BeamWidth field controls instead the number of frames between two weapon sprites, more will make the graphic frames spin slower (adjust as usual to be at the rate you wish).
Also, (still if not a beam), a positive (non-zero) value in the Falloff field defines instead how fast the shot graphic fades in the last second or so of its life; this undocumented behavior is used by the railguns for instance, and has been cornered by Edwards.
The BeamColor field This hex field, that's probably implemented as a color picker in your editor, allows you to choose the color of the beam. If there is an hex field, it's encoded the same as an HTML color (first two hex numbers unused, then each following pair being one color channel, first Red, Green, then Blue), use some tool that will give you the HTML color from a color picker to know what to enter here.
The CoronaColor field This hex field, that's probably implemented as a color picker in your editor, allows you to choose the color of the beam corona. The corona is translucent, so over the blackness of space the corona will be actually be half as bright as what you enter here. If there is an hex field, it's encoded the same as an HTML color (first two hex numbers unused, then each following pair being one color channel, first Red, Green, then Blue), use some tool that will give you the HTML color from a color picker to know what to enter here. You can put pure black (0x00000000) to have pretty much no corona.
The SubCount field This number field holds the number of submunitions that the shot explosion will create. Submunitioning is a pretty powerful but complicated feature that can be used for a number of things, like making a missile or rocket that will explode in front of a wing of fighters, thus launching a group of smaller missiles that will scatter and attempt to hit every fighter to disperse them. The only use of submunitions in the default Nova scenario is for the nanites launched by the Krypt pods and the Polaran multi-torp (check them at wëap ID 163, 182 and 185). I don't think it's a good idea to put too many submunitions. Put 0 if you don't want this weapon to submunition.
The SubType field This number field holds the ID of the wëap resource that is used to determine the kind of shot that will be submunitioned (to know which damage it should do, which graphic, which homing, etc...); it has to be a weapon that's not a beam, not point defense, not a fighter. Notice you can put the ID of the weapon you're currently filling to have the weapon shots submunition into themselves, the weapon is then said to be recursively submunitioning, you should then fill the relevant field below.
The SubTheta field This number field is the inaccuracy at which the submunitions are launched: for positive values it works just like the inaccuracy field, with the direction of the mother shot playing the same role as the direction of the launching ship. However, a negative value will be the spacing angle between the submunition shots, in degrees: ignored if there is only one, this will be the angle between the two shots if there are two, if there are three, the double will be the angle between the leftmost and rightmost shot while the middle shot will go straight front, etc... (note: maybe put some explanation pic here?)
The SubLimit field If the weapon is recursively submunitioning, this number field holds the number of times the weapon will submunition into itself so as not to leave it submunitioning an indefinite number of times and thus filling the maximum shot count (128). Otherwise, this field is ignored. Also notice there is no recursively submunitioning weapon in the default Nova scenario.
The ProxSafety field This number field holds the amount of time before the shot will be allowed to detonate after the moment it's fired, as a safety so as not to explode too soon after being launched and thus damaging the firing ship. As surprising as it seems, the shot won't explode even if it directly hits a ship until ProxSafety has elapsed, so it will go through everything during that time, excepts asteroids that can still be hit (unless you set the "pass over 'roids" flag). This can be useful for an anti-fleet weapon (such as a mine) that purposedly has a big ProxRadius and bigger BlastRadius and could be dangerous for the ship that launches it. 0 will make the shot immediately armed and deadly after launch, as are all weapons in the default Nova scenario: this feature is unused. This option is not relevant for beams.
The Ionisation field This number field stores how much ionisation each shot will add to the ionisation charge of ships in the BlastRadius (before the 1.0.8 version it only adds it to the ship hit, makes more sense now). Ionisation is a mean feature of the engine that allows some weapons to ionise ships, which makes ships thus ionised be slowed down until they dissipate their ionisation charge. Weapons such as the ion cannon and EMP torpedoes use this feature and ionise their targets.
The HitParticles field This number field holds the number of particles to generate when the shot hits. They work just like the particles that are constantly produced by the shot, just they are all lauched at once when the shot hits. Almost all weapons generate some in the default Nova scenario. Put 0 for no particle when the shot hits.
The HitPartLife field This number field holds the average life count of particles thus generated at hit, in number of frames (more makes longer-living particles). Notice that contrary to particles constantly generated by the shot there is no min and max life, just this average life expectancy (with some variation).
The HitPartVel field This number field tells the speed of these particles, in pixels per frame times 100 (more will make faster particles). You can then tell the distance these particles will cover, in pixels, by multiplying this field by the value in the above field and dividing by 100.
The HitPartColor field This hex field, that's probably implemented as a color picker in your editor, allows you to choose the color of the hit particles. If there is an hex field, it's encoded the same as an HTML color (first two hex numbers unused, then each following pair being one color channel, first Red, Green, then Blue), use some tool that will give you the HTML color from a color picker to know what to enter here.
The ExitType field This number field indicates which ship exit point the weapon shots will start from; as there is only a small number of relevant values it's probably a popup menu in your editor.
"ship center": -1 will make the weapon shots always exit from the center of the ship.
"Gun Positions": 0 will make the shots exit from the positions defined for guns in the ship shän. It's for use with guns and assimilated weapons.
"Turret Posistions": 1 will make the shots exit from the positions defined for turrets in the ship shän. It's for use with turrets and assimilated weapons.
"Guided Posistions": 2 will make the shots exit from the positions defined for missiles and other such guided weapons in the ship shän. It's for use with missiles and other such guided weapons.
"Beam posistions": 3 will make the shots (or, more than likely, beam) exit from the positions defined for beams in the ship shän. It's for use with fixed beams weapons.
The BurstCount field This number field reports how many shots the weapon will be able to fire before the end of the burst is reached (i.e. it's how many shots per burst); at the end of a burst, the weapon needs to recharge for a duration indicated in BurstReload before being able to fire anew. This is being used for instance by the hail chaingun, that fires 10 rounds then has to stop a little to reload, notice only one unit of ammunition is used for each burst. Also, if there are more than one instance of the weapon, the number of shots that can be fired before having to endure a burst reload is multiplied by the number of instances of the weapon. Put 0 or -1 if you don't wish to use.
The BurstReload field This number field stores the time, in number of frames, that the weapon will need to rest when at the burst reload. This can hurt the overall rate of fire, so consider it when adjusting the firepower of your weapons. Also, you almost need to put some to point defense weapons, to leave a window of vulnerability for the ship. It's obviously ignored if the burst reload feature is unused (i.e. above field is set to 0 or-1).
The JamVuln fields If the weapon is guided, these 4 number field state how sensititve to each kind of jamming the weapon is. The more you put, the more the missiles will be affected by the corresponding jamming systems. In the stock Nova scenario, the first field is 100 for infrared guided missiles, that are as a consequence vulnerable to infrared jamming, the second matches radar guidance, the third one gravimetric guidance, and the fourth one etheric guidance (that's used in most Polaris weapons), so put values that match the kind of guidance you tell your weapon uses.
The Durability field If the weapon is guided and can be fired on by point defense systems, this number field is the amount of damage it can receive before being destroyed, like the armor for a ship. You can set 0, it will make the missile unprotected and instantly destroyed by any point defense hit. Notice that the amount of damage done to a missile by a point defense shot is 100% of the shot's mass damage plus 50% of the shot's energy damage, so it actually receives more damage than the armor of a ship. It's considered bad to make missiles durable to the point they can't be destroyed, set them instead to be untargetable by point defense so that PD systems can better spend their time firing to destroyable things. Ignored for non-homing weapons, that cannot be fired on by PD.
The GuidedTurn field If the weapon is guided, this number field is the turning speed of the weapon; the more there is, the more maneuverable the missile is (and the harder it will be to avoid). Experiment as usual to make the missile only as maneuverable as you want it to be. Obviously ignored for other weapons.
The MaxAmmo field If the weapon uses actual ammunition (i.e. not fuel), this number field allows you to constraint the amount of ammunition the player can hold by a multiple of the number of launchers, the value put here being the number of ammunition allowed for one launcher. If there are two, the maximum amount of ammo will be twice; three, thrice; etc... This especially makes sense for fighter bays (like is done in the default Nova scenario), but can also for other ammo-using weapons where it can be imagined the tubes hold the munitions themselves in a side storage for faster reload, so the room for ammo is limited by the number of launching tubes. Put 0 or -1 if you wish the amount of ammo to be limited "normally", i.e. like all outfits by an absolute maximum value set in the ammo's oütf resource. This is ignored for non-ammo-using weapons.
The Recoil field This is the amount of recoil that will be applied to the firing ship whenever a shot is fired. 0 or -1 will make no recoil; a positive value will push the ship backwards, as recoil usually does. However, a negative value will push the ship forwards, which can make sense with -180 inaccuracy or if the weapon is a rear-quadrant turret. Notice that the ship mass is considered, like it is for impact: bigger ships will suffer from less recoil, inversely proportionally to their mass. This feature is completely unused in the default Nova scenario.
The LiDensity field If the weapon is a beam, this number field allows you to make the beam a lightning beam (such as the one of Wraiths and the TripHammer), and the value here will be the number of zigzags for each 100 pixels, i.e. putting more will make the beam more convoluted. Notice that lightning beams have no corona, they don't have any purpose other than looking cool, and Matt Burch issues a warning not to overuse lightning beam as they are quite processor-intensive; see also Guy's quote for other differences. Put 0 to have the beam remain straight.
The LiAmplitude field If the weapon is a lightning beam, this number field holds the amplitude of each zigzag in pixels: higher values will make bigger zigzags (did I say to experiment to find the value to give?). However, warning is issued that putting too high values will give the player screen redraw problems, so Matt says: don't overdo.
The IoniseColor field This hex field, that's probably implemented as a color picker in your editor, allows you to choose the color to affect ships that have been ionised with this weapon. If there is an hex field, it's encoded the same as an HTML color (first two hex numbers unused, then each following pair being one color channel, first Red, Green, then Blue), use some tool that will give you the HTML color from a color picker to know what to enter here. You can leave 0 for a default blueish color to be used.
There can be a maximum of 256 weapon types, which means wëap resources can have IDs from 128 to 383.
This post has been edited by Zacha Pedro : 21 March 2005 - 08:14 AM
EDIT: Nevermind. Where's the delete button? Meh...
This post has been edited by orcaloverbri9 : 06 September 2004 - 07:02 PM
Zacha, you should add the thing about the falloff field mentioned in a recent topic here:
Edwards, on Dec 28 2004, 05:27 AM, said:
When used for a non-beam weapon, the Falloff field defines the how fast a weapon will fade out during approximately its last second of life. Lower numbers give slower fades (Railguns and Fusion Pulse Cannons use 2). Negative numbers seem to have no effect.
Also, the BeamLength field, if set to a positive number for a non-beam weapon, will make said weapon fade out instantly approximately one second from the end of its life. This is overridden by the Falloff field. View Post
Also, the bit about subtheta isn't quite right. The behaviour you describe only occurs with negative values. Positive values are random, like positive inaccuracy.
Thanks a bunch; the info will be added in the 'changes in my guides' topic in a few minutes.
It's update time...
Recent revealings about how weapons work (no more than one shot a frame for non-simultaneous firing weapons, beam display, damage, and other odd beam stuff, etc...) forced me to amend this guide. By the way, could you confirm that you allow your info to be included, Guy?
Here are the changes:
Reload field: This number field holds the minimum amount of time between two shots of the weapon, in frames (that are 1/30th of second), which dictates its rate of fire when the weapon is fired continuously. The frame is the base unit of time in Nova, so get used to it now. Notice that firing a shot already takes one frame by itself, so 0 is a perfectly valid value, there will just be no reload interval and one shot every frame (30 a second). If 1, there will be one frame for firing the shot, then one frame for reload, then the weapon will fire again, so there will be one shot every other frame (15 a second). If 2, one shot every 3 frames (10 a second). Etc: if n, one shot every n+1 frames (30/(n+1) a second), which is not really different from n when n is big.
This is for the case when the ship owns only one (no more) instance of this weapon. If the ship owns more than one launcher (say m), shots are fired one by one, but every (n+1)/m frames, with an important limitation: there can't be more than one shot per frame, regardless of the number of launchers. This means a weapon with a Reload of 0 already fires as fast as it can when the player owns one, so there is really no point in owning a second launcher. A weapon that has a Reload of 1 will already fire every frame when the ship owns 2 of it ( (n+1)/m=(1+1)/2=1 ), so the player won't benefit from owning any more launchers, as no more than a shot can be fired per frame, and he already fires one a frame with two, so he will still fire one shot a frame with 3, 4, or more launchers. Same thing is Reload is 2, 3, etc: owning more than Reload+1 instances of the weapons is useless to the player. As a consequence, adjust the "Max" field of the o¨tf resource matching the launcher to Reload+1 or less, so that the player does not buy more launchers than what's actually useful. This is true for beams as well: even if they don't have "shots" so to speak, they still can't "fire" more than once per frame, and since their damage is applied differently, you might as well give an important value (say 20-30) here and in the Count field.
There are two exceptions to the limitation above. First, if the weapon has the "fire simulateously" flag set, then m shots will be fired together (in the same frame) every n+1 frames, so having m launchers is always m times as efficient as owning one. Second, if the weapon has a burst reload, then the player can always benefit from owning more launchers as even if the firing rate does not increase, he will be able to fire more shots before having to endure a burst reload (whose length is constant), which is good overall (though not m times as efficient); a good example is the chaingun cannon, experiment with it.
(at the end of energy damage:)
Notice damage is applied differently for beams: while non-beam weapons apply their damage once per shot, MassDmg/EnergyDmg is applied every frame the beam hits the target ship. This means that these two fields are usually set to lower values than for other kind of weapons, and changing the Reload/Count pair won't change the damage.
(after BeamLength:)
The following information about beams has been investigated and documented by Guy (yes, (link)Guy(/link)). In fact, he already put it very well (of course, since it's about beams, he means the BeamWidth field with Width):
-temporary snip, waiting for approval before I include the contents of the first post in this topic.-
(ProxSafety:) This number field holds the amount of time before the shot will be allowed to detonate after the moment it's fired, as a safety so as not to explode too soon after being launched and thus damaging the firing ship. As surprising as it seems, the shot won't explode even if it directly hits a ship until ProxSafety has elapsed, so it will go through everything during that time, excepts asteroids that can still be hit (unless you set the "pass over 'roids" flag). This can be useful for an anti-fleet weapon (such as a mine) that purposedly has a big ProxRadius and bigger BlastRadius and could be dangerous for the ship that launches it. 0 will make the shot immediately armed and deadly after launch, as are all weapons in the default Nova scenario: this feature is unused. This option is not relevant for beams.
About the guide (I wasn't around when it was first posted, but as long as it's here...):
Very nice. Accurate. Although I hope it will look less dense when it's converted to HTML .
Also, if you're taking any suggestions (feel free to ignore any of these):
Negative Innacuracy: The types of weapons affected are Unguided, Turreted Unguided, and the Front and Rear Turrets. The Freeflight Rocket guidance type is also affected, but only for AI ships.
Small Smoke: The Bible has a very bad explaination of smoke trails. What the Small Smoke flag does is display the first three cicns in order, and then display them again in reverse (like this: 123321). The Big Smoke flag displays the entire series of eight cicns, but it is overridden by the Small Smoke flag. The Persistant Smoke flag causes each cicn to be displayed three times in the smoke trail: 111222333444555666777888 (or 111222333333222111). If you do not have either big or small smokes selected, the weapon will not generate any smoke.
Picky little detail: In 1.0.8, the side blind spots are used for some weapons; the Fusion Pulse Battery, the Light Blaster, the Light Cannon, and the BRL. All of these were probably originally intended to be front-quadrent turrets with a tracking glitch when the target is moving straight at them.
Planet-type Weapons: The "Explode at End of Life" flag doesn't work properly for planet-type weapons. It will show the proper bööm, but that's all. No damage, no ionization, no impact.
Burst Reloads: If you have one weapon with a burst reload, and it has the "Uses Ammunition on Burst Reload" flag set, it will use one unit of ammunition every time it fires BurstCount shots. If you have more than one, it will multiply the number of shots between reloads by the number of weapons you have, but it will still use one unit of ammunition every time you fire BurstCount shots.
Zacha Pedro, on Mar 17 2005, 05:23 PM, said:
Recent revealings about how weapons work (no more than one shot a frame for non-simultaneous firing weapons, beam display, damage, and other odd beam stuff, etc...) forced me to amend this guide. By the way, could you confirm that you allow your info to be included, Guy? View Post
Certainly.
Zacha Pedro said:
(of course, since it's about beams, he means the BeamWidth field with Width):
Oh yeah. Fixed now.
Just a couple of errors. Missed a 'u':
... the o¨tf resource ...
Spelling:
... "fire simulateously" ...
Edwards said:
The Persistant Smoke flag causes each cicn to be displayed three times in the smoke trail.
Odd, it was only twice in EVO. Also, if you had caps lock it would skip every other frame and make it look really screwed up.
I'm sorry, Zacha Pedro, I wasn't paying attention for the start post, could you please repeat yourself?
Sigh- Class, please always pay attention. I don't like to repeat myself. Fnoigy, you can find a recording of the session at the beginning of the thread. Listen it while the others take a break and I answer their remarks.
Intersting stuff, Edwards. I've added some of it, though most are more advanced information and not really for a guide.
Thanks a bunch, Guy. Added, fixed, fixed, fixed.
When we compile this stuff, we should add it in two tiers: beginners and advanced.
Edwards and I (and others) have written some stuff that is usefull to advanced designers, but way over the heads of the average newbie that just needs help understanding the terse explanations of the bible.
Id be glad to help start the proper html-ification of all of this stuff, with all of the cross linking and things. I just dont have a good host at the moment.
(Recalibrating information level. . . .)
All right. Here are a few spelling and information errors. All technical details have been carefully tagged .
At the beginning, you may want to add that the semi-colon does work for comments in weapon names.
Freeflight guidance type said:
...the shots will start at a small velocity then accelerate to the maximum speed...
The speed they start at is the same as that of the launching ship. And you may want to add an "and" between "velocity" and "then".
Rear-quadrant guidance said:
rear swivel pulse cannon
Technically, it's the "Rear Phase Cannon".
AmmoType section said:
...Blaster of Fusion Pulse Cannon.
Amazing how large an effect such a little typo can have...
Impact section said:
-1
Shouldn't this be "<0"? Also, inertialess ships are affected by tractor beams. (technical detail)And, at least in my experience, a "tractor beam" actually only locks the two ships' velocities together, keeping them exactly the same distance from each other.(/technical detail)
Flak flag said:
anti-aerian
I would guess that you wanted "anti-aerial" there, although in my opinion "anti-air" or "anti-aircraft are more standard english words for that meaning. "Anti-aerian" does give an interesting meaning if you read it out loud, though, given the context...
Doesn't submunition when expiring flag said:
This is probably ignored if the flak flag is set as it will act as if it hit and launch submunitions in that case.
I've tested that one, and no, it is not ignored when the flak flag is set.
(technical detail)
SubType said:
...it has to be a weapon that's not a beam, not point defense, not a fighter.
Actually, Matt Burch seems to have changed that. When they are used as submunitions, they act exactly like their guidance type is "unguided". Making them pointless to use, anyway <_< . Well, in the case of beam guidance types, there is a difference. The Falloff and BeamLength fields do not have any fading effect. This seems to indicate that the game uses the same code for the actions of submunitions and weapons fired by spobs.(/technical detail)
About negative recoil: Alas, it doesn't work on the player's ship . It works fine for AIs, though.
Finally, be sure to change "developping" to "developing" in all of your guides. Also search for "ennemy".
EDIT: Oh, yes, and there's a misplaced semicolon in the middle of "weap" in the last line.
This post has been edited by Edwards : 18 March 2005 - 04:11 PM
Not that I mind, but I was just curious: Why have you inlcluded a link to my profile?
Well, because if someone who does know you read this, he will wonder "Guy? which guy?", so I have to say you're EVDC member.
Thanks for the corrections and nitpicking Edwards, that's more useful (for the purpose of this guide) than over-the-top technical details.
Zacha Pedro, on Mar 21 2005, 01:12 PM, said:
Well, because if someone who does know you read this, he will wonder "Guy? which guy?", so I have to say you're EVDC member. View Post
Heh heh. Fair enough then.