Ambrosia Garden Archive
    • Esoteric Nova Knowledge Compendium


      OK, it's actually nowhere near as cool as the title makes it sound. This is really just a list of interesting Nova factoids I've stumbled across while mucking around and that I haven't seen listed anywhere else on the forums.

      General AI Behavior
      The AI will never fire turrets at ships that are marked as untargetable -beam or projectile - even if they are the 90° swivel variety (which can be fired without acquiring a target). However, the AI will fire guided weapons at said ships, which means that you have to 1) live with it and let the AI cheat 2) make all untargetable ships have 100% jamming against all seeking weapons and let the AI waste its ammo or 3) make all guided weapons sub from a turret. This, however, does not seem like the greatest solution as I can't figure how you'd make the missiles exit in the right direction.

      On that note, the AI will, as far as I can tell, never fire turrets that are marked as having a front blind spot. I'm not 100% on this, but it's extremely annoying and I don't really see any good workarounds other than simply not giving the AI broadside or rear turrets (pretty easy, but still irritating).

      The AI won't even fire planet-type weapons at non-planet-type ships, nor will it fire non-planet-type weapons at planet-type ships. Score 1 for Nova's AI.

      AI ships will also fire planet-type beams at planet-type ships; however, they will not collide. As far as I can tell, planet-type beams will never hit anything.

      When calculating the max range to fire a weapon, the AI does not take into account the flag "subs fail when shot expires." This means that the AI will start firing such weapons when still out of range assuming the subs' life is significant (such as in a persistent-damage weapon). This can be worked around, but it takes some doing if you want it to be "fair" assuming it drains ammo or energy. First, make two new weapons. One will be a facsimile of the weapon, but with very, very low ammo/energy consumption (you can use long bursts fire mechanics along with the "only drain ammo at end of burst" to accomplish this). This means that firing the weapon while out of range will not drain the ship's reserves. The second weapon will not deal damage and will be invisible, but will fire and draw ammo at the rate of the original weapon. It should also have the same count and duration. Give these to all AI instances of the ship, using cröns to replace it if the player ever gets a hold of them. That way, firing the weapon wildly will not penalize the AI, but it will drain ammo/energy when using it effectively.

      Carried Fighter Behavior
      Carried fighters with <100 max energy will be left behind if you hyper without docking them first. They will follow you through hypergates and wormholes. I know this has been brought up before (in the Delphi thread?) but I don't think it's common knowledge. It does present some interesting opportunities.

      Carried fighters marked as a planet-type ship will do almost nothing when launched. Even if attacked, they will generally just drift. I have not tested giving the player planet-type fighters. This is typically not an issue, but it eliminates this as an option for representing a universe in which fighters are only vulnerable to point-defense weapons.

      Cloak-Related Behavior
      All ships (even escorts and fighters) marked as "cloaks while flying" will always cloak if they have the energy and shields to do so. Note that while the player can maintain a shield-draining cloak while at 0% shields, the AI cannot.

      Cloaked escorts and fighters cannot be targeted by opt/alt-tab, but they can be targeted by click targeting.

      Marking a ship as "cloaks when entering hyperspace" will make a player-controlled instance of said ship able to jump without decloaking. This is, to my knowledge, the only AI behavior ship flag that affects the player's ship.

      Mission Bit-Related Behavior
      Running the sxxx command works as stated in the bible, with one nuance. Any mission started by the completion string of another mission will run before the completion text has displayed. This means that if mission 100 starts mission 101 on completion, mission 101's "accept" text will run before mission 100's "complete" text. Easy to work around; just switch the texts. I'm sure this must have been brought up before, but again, I don't think it's well-known.

      If Nova runs either Exxx or Hxxx (the two commands that give the player a new ship with all the outfits included), and ship xxx has more of any outfit than that outfit's max #, the player's count for said outfit will be reduced to the outfit's max #. This can be boosted above the max # by simply making the string run Gxxx repeatedly.

      On the same note, Exxx and Hxxx will grant fighter bays, but it will not grant the carried fighters. My guess is that this is because unless the player's current ship has bays for the appropriate fighter, it cannot carry any fighters when the bit fires and has them stripped as per the above behavior. I can then assume that any weapon whose ammo load is controlled by the MaxAmmo field in its wëap resource will exhibit the same behavior. This is very easy to work around.

      Outfits and Weapons
      If weapon Y is marked to draw ammunition from weapon Z (modifying my variables to avoid any unintentional X-Men references), any ship which carries weapon Y will display free mass in the shipyard info box as too high by an amount equal to the mass of weapon Y's ammo load. This can be worked around by making an alternate version of the ship to appear in the shipyard and switching it using Hxxx, although you may run into the aforementioned fighter problem (which is also easily solved) if it carries fighters.
      As an aside, I hope someone puts that knowledge to good use; I spent hours upon hours trying to figure out why one of my ships always displayed 114 free tons instead of 50.

      Related to the above, any weapon that draws ammunition from another weapon whose max ammo load is controlled by the "MaxAmmo" field in its wëap resource will not be able to carry any ammunition. For example, if weapon Y is marked to draw ammunition from weapon Z and weapon Z can carry 50 ammo per instance of weapon Z, weapon Y will be able to carry 0 ammunition (since it and weapon Z use the same ammo). You can get around this by making weapon Y's öutf resource also carry a ModMax field for the appropriate ammunition type. I have not tried this, but it is theoretically sound as far as I can tell.

      The "Immune to PD" flag in the wëap resource does not mean what it says; rather than make the weapon immune to PD, it simply means that PD will not fire at it (much like point-defense will still hurt non-fighter ships). Still, as guided weapons are the only type that PD can hurt, this only impacts PD-"immune" guided weapons. Not quite perfect, but can be worked around by giving the weapon in question a huge durability.

      Weapons that have not hit their ProxSafety (meaning that under no circumstances will a ship trigger it) will still be triggered by asteroids (assuming they are not flagged to pass over asteroids).

      PD-vulnerable weapons with durability of 0 will work perfectly well, but will be shot down by any point-defense weapon – even if the PD deals 0 damage.

      Display weight is not constrained to 0-100 as you see in stock Nova. However, any outfit with a display weight <0 will display improperly in the "extras" dialog box. After the lowest positive- or 0- weight outfit is listed, you will simply see "and ." (That's not a typo; it's the word "and" followed by a space followed by a period.) However, if marked to show up in Ranks and Honors instead of Extras, it will display correctly. Easy to work around; just bump up all the display weights.

      Exclusive Fire does not behave quite as it is described. Rather than nothing being able to fire while the EF weapon is firing, it means that nothing else can fire while the EF weapon is firing or reloading. You can use this to produce some interesting effects, such as tinkering with the count/reload/burst count/burst reload fields of beams to make a beam that will fire for, say 8 seconds and shut off all other weapons for, say 6 seconds.

      Well, that's it for now. I hope someone finds this useful. If anyone has questions feel free to fire away, but be advised as I haven't had much time for forums recently (this has been sitting around for a few months now). I'll edit in any corrections or addenda you come up with.

      This post has been edited by Archon : 24 February 2010 - 10:25 PM

    • QUOTE

      Running the sxxx command works as stated in the bible, with one nuance. Any mission started by the completion string of another mission will run before the completion text has displayed. This means that if mission 100 starts mission 101 on completion, mission 101's "accept" text will run before mission 100's "complete" text. Easy to work around; just switch the texts. I'm sure this must have been brought up before, but again, I don't think it's well-known.

      To my knowledge, this is wrong. I've done some fiddling with missions before, this is one of them. I have not seen the mission started by Sxxx show its brief desc before the previous mission shows its completion desc under any circumstances.

      I am on a Mac, though, and do not know what system you use, Archon. If you use a Windows machine, then that instance is Windows-exclusive and does not occur on Macs. If you are using a Mac, however, then I do not know how you saw that.

    • Good work Archon!

      QUOTE (Archon @ Feb 24 2010, 10:17 PM) <{POST_SNAPBACK}>

      Mission Bit-Related Behavior
      Running the sxxx command works as stated in the bible, with one nuance. Any mission started by the completion string of another mission will run before the completion text has displayed. This means that if mission 100 starts mission 101 on completion, mission 101's "accept" text will run before mission 100's "complete" text. Easy to work around; just switch the texts. I'm sure this must have been brought up before, but again, I don't think it's well-known.

      Moreover, the Sxxx'd mission will in fact be started before the completing/failing/aborting mission has gone away. That means if the player has 16 active missions, the new one will not be started. No warning will be given, the old mission will end, and the player will have only 15 active.

      QUOTE (Archon @ Feb 24 2010, 10:17 PM) <{POST_SNAPBACK}>

      On the same note, Exxx and Hxxx will grant fighter bays, but it will not grant the carried fighters. My guess is that this is because unless the player's current ship has bays for the appropriate fighter, it cannot carry any fighters when the bit fires and has them stripped as per the above behavior. I can then assume that any weapon whose ammo load is controlled by the MaxAmmo field in its wëap resource will exhibit the same behavior. This is very easy to work around.

      My guess is that it's for the same reason a chär set to start in a ship with fighters will have zero fighters when a new pilot is made with that chär. I doubt anything beside Gxxx can fix it.

      QUOTE (Archon @ Feb 24 2010, 10:17 PM) <{POST_SNAPBACK}>

      Related to the above, any weapon that draws ammunition from another weapon whose max ammo load is controlled by the "MaxAmmo" field in its wëap resource will not be able to carry any ammunition. For example, if weapon Y is marked to draw ammunition from weapon Z and weapon Z can carry 50 ammo per instance of weapon Z, weapon Y will be able to carry 0 ammunition (since it and weapon Z use the same ammo). You can get around this by making weapon Y's öutf resource also carry a ModMax field for the appropriate ammunition type. I have not tried this, but it is theoretically sound as far as I can tell.

      I suspect that is theoretically false. ModMax affects one cap on how many of an outfit can be bought. MaxAmmo affects another. The maximum that can be bought is the minimum of all the caps.

      QUOTE (Archon @ Feb 24 2010, 10:17 PM) <{POST_SNAPBACK}>

      The "Immune to PD" flag in the wëap resource does not mean what it says; rather than make the weapon immune to PD, it simply means that PD will not fire at it (much like point-defense will still hurt non-fighter ships). Still, as guided weapons are the only type that PD can hurt, this only impacts PD-"immune" guided weapons. Not quite perfect, but can be worked around by giving the weapon in question a huge durability.

      Weapons that have not hit their ProxSafety (meaning that under no circumstances will a ship trigger it) will still be triggered by asteroids (assuming they are not flagged to pass over asteroids).

      PD-vulnerable weapons with durability of 0 will work perfectly well, but will be shot down by any point-defense weapon – even if the PD deals 0 damage.

      Good finds.

      QUOTE (Archon @ Feb 24 2010, 10:17 PM) <{POST_SNAPBACK}>

      Exclusive Fire does not behave quite as it is described. Rather than nothing being able to fire while the EF weapon is firing, it means that nothing else can fire while the EF weapon is firing or reloading. You can use this to produce some interesting effects, such as tinkering with the count/reload/burst count/burst reload fields of beams to make a beam that will fire for, say 8 seconds and shut off all other weapons for, say 6 seconds.

      That is exactly how my Nova Bible describes it. On a related note, burst-firing weapons that are not set to fire simultaneously behave as follows: The number of shots that can be fired before the BurstReload kicks in is the number copies of the weapon times the BurstCount. The delay between shots within a burst is exactly the same as it is for normal non-burst weapons. Namely, n weapons reload n times faster than one, but no faster than one shot per frame. What this means, in practical terms, is that the number of frames that burst goes on for does not depend on the number of copies of the weapon, until that number is enough to push the reload down to zero. Then the burst lasts the same number of frames as the number of weapons owned times BurstCount.

      I'll probably have more to add to this thread when I have time. But for now I'll just say that !Pxxx works exactly as one would expect.