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).
Welcome to BugFest '05, the newest compilation of bugs in Escape Velocity Nova. Please post the most annoying bugs you've found in the game engine, and comment on the bugs other people post.
The Rules:
Now, my bugs:
In the öops resource, Stellar type -2 (no spob- news only) seems to prevent the öops from ever occuring. (Note: The nova Bible states that this should work, but cröns have taken over the effect.)
In the shďp resource, the "immune to gravity" flag has no effect, and the "immune to deadly stellars" flag makes the ship both immune to deadly stellars AND immune to gravity.
Planet-type weapons, when they "detonate at end of life", do not actually have any effect. All that happens is that they display the appropriate bööm. No damage, no impact, no ionization, etc.
Planet-type beams DO NOT DO ANY DAMAGE. They pass right over any destroyable spobs and planet-type ships they intersect.
When you fire a weapon with a ProxRadius, when it explodes, it will not just do damage and ionization to all ships within the BlastRadius. It will also do damage and ionization to the lowest internally numbered ship within the range of ProxRadius. (The internal numbering system for ships, in this context, is the order in which they are created in the system. This is also the order in which you cycle through ships in the system with the "ship select" key.)
---------- Can you tell that I've been doing a lot of work with planet-type weapons? (If planet-type weapons are representative of how messed up other aspects of the game engine are... shudder)
Edwards
Edwards, on May 7 2005, 08:57 PM, said:
More likely than not, that's probably just a feature that was thrown out early on, but Matt forgot to remove the documentation. It happens. A prime example is the missing feature for using negative dudes to reference fleets in missions that caused UE R&D so much pain.
While it's not an overly serious bug, this is still a bit annoying. For some reason, if you make a one-time debug pilot (don't include a name), it says a pilot with that name exists. Pardon? I don't think there's a file named "" in my Pilots folder.
This is running on EVN 1.0.8 with Mac OS X 10.4 (Tiger).
This post has been edited by orcaloverbri9 : 07 May 2005 - 11:51 PM
Here are my additions to the list-
öops resource bug: One is led by the Nova Bible to believe that if the öops ActivateOn test evaluates to a TRUE state and simultaneously the Freq parameter is set to 100% then the öops should be activated. But this is true ONLY if the NCB used in the ActivateOn statement is between b0 and b191 (or maybe up to b511, I didn't test that yet) inclusive. This is a case of holdover legacy behavior from either EV-Classic (if b191 is the upper limit) or EV-Override (if b511 is the upper limit).
<PRKnnn> and <SRKnnn> bug: These two dësc resource variables only return the string "<PRKXXX>" or "<SRKXXX>" regardless of whether or not a player ränk exists for gövt XXX. (edit) fixed a bug in my bug report (/edit)
mďsn resource adjacent s˙st AvailStel bug: If you use the 5000 to 7047 values to define an adjacent system for the AvailStel the mission will never be offered if any spöb in any of the adjacent systems is transient (i.e.- doesn't exist for all versions of the adjacent system). The key point here is that it only takes just one spöb in just one adjacent system to be transient and the game-engine simply quits trying to find any other adjacent system spöbs that are non-transient.
mďsn resource classmate AvailStels, TravelStels, and ReturnStels bugs: The classmate values (30000 thru 30255) also have the same problem as the preceding adjacent system bug. If the specified gövt or any of its classmates has even just one transient spöb, no mission is offered. In my humble opinion the whole restriction concerning random selection of only non-transient spöbs is a broken idea, but that's just me.
mďsn resource CompReward deduction on mission failure bug: And no, this is not about the "-5x Reward on abort" flag. This is about the bible CompReward note that says ... "If you have a CompGovt and CompReward defined and you fail the mission, that govt will take it personally and decrease your record by 1/2 the amount specified in CompReward." This does not happen.
crön PostHoldoff (ugly) bug: Elaborated on here.
ränk resource bug: This is probably just a documentation error. The bible ränk resource section states that the PriceMod is "Used to modify the prices of items and ships at stellars owned by the affiliated government." PriceMod only affects shďp prices, but not outfit prices. This is of course assuming one accepts that the "items" referred to are actually outfits.
Escape shďp bug: This is kind of picky, but you asked. If you classify a shďp as a substitute for the escape pod with the "Escape ship" flag bit of the shďp resource and then eject using that escape ship, the game-engine still names it "Shuttle xxxx". I know, like I said ... picky.
spöb resource TechLevel bug: This is another picky one. Outfits with a TechLevel of zero do not appear in the outfitters of spöbs with a base TechLevel of zero. This contradicts the bible spöb TechLevel statement that "Only items and ships with TechLevels at or below this value will be available."
These have all been verified by testing in EV:N v1.0.8
This post has been edited by Arturo : 09 May 2005 - 01:42 AM
Well known windows bug: Attack enemy spob AI behavior crashes PC version, and the char rescource doesnt let you use any resource but 128 (no choice).
Confirmed in every version ive played, newest of both mac an PC: Many bad things happen when the system fills up with ships. Like, for example, if you have 6 ravens and are demanding tribute, the system will fill up. When it does, you cant launch your fighters (obviously, but this is ok), and as new defense ships are produced, they are always highest up in the system ships id (or whatever its supposed to be called.) When one of them dies, it clears a slot for you to launch a fighter, but every multitorp locked on to the recently dead ship now locks onto your fighter. The torpedo remenbers what sysID ship it was chasing, but forgets to go inert when its target dies, and if you are holding down secondary fire, your fighter inherits its id without that id slot spending a frame empty (this is probably critical.)
Anyway, this isnt really a bug relevant to plugin makers, except that it is a bad idea to create any sort of situation that might fill the system up.
This post has been edited by NebuchadnezzaR : 09 May 2005 - 02:29 AM
NebuchadnezzaR, on May 9 2005, 07:07 AM, said:
Anyway, this isnt really a bug relevant to plugin makers, except that it is a bad idea to create any sort of situation that might fill the system up. View Post
I remember in EVO if you did that you'd end up with 33 ships in the system. A ship dies then a new one spawns and a fighter is launched. Very odd.
As for bugs, this one's always annoyed me: PD weapons will not target ships which have gone into retreat mode, even if they haven't retreated yet and are still attacking you. Eg, your attacker runs out of ammo and is now flagged to retreat but won't until it is out of range. It continues to attack with its primary weapons but your PDs will no longer respond.
This post has been edited by Guy : 09 May 2005 - 03:11 AM
Maybe there are a few extra slots just to ensure a defense fleet will exist.
I just want to ask; have these or will these bugs be reported to the developers via the "proper" channels, and not just in this forum post?
Are bugs which have already been reported welcome here anyway?
Weepul 884, on May 9 2005, 10:32 AM, said:
Are bugs which have already been reported welcome here anyway? View Post
mburch, on Dec 28 2003, 01:31 AM, said:
The issue with ionizing weapons was done that way by design, but I have now changed it due to popular demand. I have also fixed the issue with the weapon submunition flag and the govt color field mentioned elsewhere in this thread.
Regarding bug reports, Ambrosia handles technical support for the EV games, and the official and proper way to submit them is, and always has been, to send Ambrosia email at help@ambrosiasw.com. However, it seems that bug reports sent there seem to somehow not get passed along by Ambrosia. If pipeline has volunteered to coordinate scenario development bug reports (with emphasis on "if") then I will do my best to deal with anything he sends my way. Obviously, we will not be able to reply to or address every issue, and I rarely have time to sort through these webboard posts, so this is probably not the most reliable place to submit things.
happy new year, mcb View Post
mrxak, on Dec 28 2003, 04:54 AM, said:
I suppose if someone were to send an email to me, I could forward it to the beta list as well. View Post
Emphasis mine.
This post has been edited by Eugene Chin : 09 May 2005 - 08:43 AM
Hmm... I was leaning towards using this thread as a guide for what developers need to work around, assuming perhaps improperly that there is no chance for embetterment.
Recoil for Turreted, Arc-firing, and Negative Inaccuracy Weapons Positive recoil values always make the firing ship accelerate in the direction opposite the way they are facing (that is, backwards) even when the weapon fires in a direction other than forwards.
Negative Recoil Simply put, negative recoil doesn't work. Ever.
Impact Getting hit be a shot with impact does not necessarily accelerate you away from the explosion. I have not tested this exhaustively, and can only offer the following anecdote: When flying a manta and being fired on by railguns, if I turn my ship so that the incoming shot strikes its side, my ship moves backwards. See image: (attachment=607:attachment)
This post has been edited by Qaanol : 09 May 2005 - 11:29 AM
Eugene Chin, on May 9 2005, 06:38 AM, said:
Emphasis mine. View Post
Yeah...actually, I did submit the bugs I found (rather minor ones, mostly) to mrxak.
Qaanol, on May 9 2005, 09:28 AM, said:
Simply put, negative recoil doesn't work. Ever.
I thought I had found that it did work, sometime in the past. Maybe in an older version of Nova?
Quote
Impact Getting hit be a shot with impact does not necessarily accelerate you away from the explosion. I have not tested this exhaustively, and can only offer the following anecdote: When flying a manta and being fired on by railguns, if I turn my ship so that the incoming shot strikes its side, my ship moves backwards. See image: attachment View Post
Were you afterburning? When testing this, I had found that a shot will knock your ship in the direction the shot is heading, even if your ship runs into the back of the projectile and it explodes with blast radius. If you're afterburning, any impact will cause your ship to slow down, I think. That might seem like "moving your ship backwards".
Weepul 884, on May 9 2005, 08:59 AM, said:
Were you afterburning? When testing this, I had found that a shot will knock your ship in the direction the shot is heading, even if your ship runs into the back of the projectile and it explodes with blast radius. If you're afterburning, any impact will cause your ship to slow down, I think. That might seem like "moving your ship backwards". View Post
Nope, just sitting there.
It only makes me go backwards if it hits me abeam, so I can use this effect to tack back and forth, letting my very light fighter get in close to the railgun source, rather than knocked back away therefrom.
I should note that I'm playing EVN for Mac v. 1.0.7
NebuchadnezzaR, on May 9 2005, 06:44 AM, said:
Hmm... I was leaning towards using this thread as a guide for what developers need to work around, assuming perhaps improperly that there is no chance for embetterment. View Post
That's pretty much what I was thinking with this thread (that and that with the planet-type beams bug, I had just gotten truely fed up with the game, and needed to let off some steam). And yes, old bugs are welcome, a long as they exist in the newest version of the game (either Mac or Windows). You may wish to mention if they've been reported to Ambrosia, though.
Negative Recoil Simply put, negative recoil doesn't work. Ever.View Post
Not quite. As of version 1.0.8, negative recoil works perfectly well for AI-controlled ships, but not at all for the player. Just like negative inaccuracy for free-flight rockets.
This post has been edited by Edwards : 09 May 2005 - 12:39 PM
xak's taking a month off, so he won't be sending any bugs in to us for a while.
These all sound pretty important, so why not send them to me, by mailing me at pipeline@atmos.com.au?
One final note: any bug in the engine that is not uncovered by the stock scenario is unlikely to be changed, unless it's trivial. It's far more likely that we'll simply change the resource bible to accomodate the changes. The reason for this is that EVN is far too hacked together to make any more major changes.
best always,
Dave @ ATMOS
ps. I'll look through what's already in this thread for bugs to send on, but future bugs to me, please.
I think that is unfortunate- that we're basically going to have to use an unfinished engine! But I have no room to complain really, I guess...
Windows-only bug:
If you convert a jpeg into a pict and use it in a plug, there's a good chance WinNova will crash when it tries to display the image. To be safe, convert all images to bmp or tiff before importing them into a plug.
Dual- (and maybe even triple, but haven't played with that quite so much) storyline exploit. My Unrelenting launches Mantas and would fire CPLs if my 6500 didn't bring its framerate down to .1/sec.
EDIT: MacNova 1.0.8
This post has been edited by The Apple Cřre : 11 May 2005 - 08:16 PM
Thats a scenario bug, not an engine bug. And good job not explaining any of it at all.
I might as well chuck a few that I've found here. All Mac EVN 1.0.8.
----------
Turrets with blind spots, or swivel weapons, can fire toward their blind spots if the weapon exit point is sufficiently far from the ship that a target can be in the correct direction from the ship center, but in the wrong direction from the weapon exit point.
This is minor, and I doubt it would really affect the base scenario - it's just a little odd.
Note: I've actually only tested it with front-quadrant-swivel cannons. I don't know for sure whether it would happen for blind-spot turrets.
Certain weapon functions seem to be based on 1/30ths of a second, and some on the framerate. For example, if I made a beam weapon with reload 15 and count 15, it ought to appear constant (or perhaps with a one frame break, since reload is delay between firings). However, my computer plays EVN at about 47 FPS. Reload appears to be based on 1/30ths of a second, while count appears to be based on frame rate. The aforementioned beam has a significant gap in its firing.
This doesn't affect its damage per second, since it creates the same number of damage-inflicting frames per second, it's just that those frames pass faster than they "should".
However, weapons that fire every frame, such as Hail Chainguns and BioRelay Lasers are affected quite a bit. A full Hail Chaingun burst does indeed take longer to completely fire if the framerate is decreased - I accomplished that by flying over a ridiculously large test planet graphic. In practical use, this might have an affect depending on how fast the user's computer is. Anyway, for such weapons, this definitely affects how much damage they can put out per second, and does affect the Nova scenario.
And just for completeness of information, as I flew over the ridiculously large test planet, the gap in the aforementioned 15/15 beam's firing pattern shrunk to the point where the beam lasted longer than its firing rate, visible by a slight bright pulsing of the beam.
I have no idea how this bug could be fixed without major engine changes in the way it handles timing.
This may or may not significantly affect the EVN scenario, depending on how much framerate variance there is when EVN is played on computers of different speeds.
Just making sure people don't forget that beam damage with beams when the player owns enough such that they would fire faster than once every frame is still messed up. As as some other board members and myself found in another thread, beam damage seems to work perfectly against asteroids, inflicting the proper damage no matter how many of a beam are owned and no matter their firing rate...so I know it's possible for the engine to do this correctly. Let's get this applied to vs. ship damage, please.
This affects the EVN scenario significantly.
This isn't necessarily a bug, but is a feature that doesn't work like I'd expect. Circumstance: a ship with a beam that has a long count (meaning it stays on screen for a good period of time after the player presses fire), a weapon glow effect, and which unfolds to fire. The weapon glow will remain visible for as long as the beam is visible, regardless of whether the player holds down the firing key. However, the ship will refold shortly after the player releases the fire key.
I'd expect the ship to stay unfolded as long as the ship has weapons actively firing, key press or not. I made note of the way the ship's weapon glow works because it shows that the engine can indeed keep track of how long a beam weapon is emitting independent of key press. How about applying that to when a ship re-folds?
This doesn't affect the EVN scenario , but since the engine is already capable of doing this, how much work would it be to plug it into refolding? I admit, I have a selfish reason for wanting this change, I want to make a ship that works like this. But it still seems like currently works in a way that doesn't make sense.
So yeah, those are mine. Edit: and now, emailed to pipeline.
This post has been edited by Weepul 884 : 12 May 2005 - 01:47 PM
I might as well point out my favorite bug, the "Follow the leader, fighter swarm bug", which works like this:
When a ships (player's or AI's) fighters are operating in a swarm one fighter is chosen to be the swarm leader. This fighter flies like a normal ship, heading straight towards the enemy, firing each weapon when in range like a normal ship and so on. All the rest of the fighters go into follow the leader mode. In this mode it looks like instead of going after the target ship they attempt to follow the swarm leader. When a fighter in follow mode gets within primary weapon range of the target it switches out of follow mode and acts as if it were a normal fighter. When it gets out of primary weapon range of the target it goes back into follow mode. Also a following fighter is will not use its afterburner, which becomes very important later on as you'll see.
This actually works pretty well, when a swarm of fighters surrounds a larger ship it confuses the target ship and allows the swarm to cause a good bit of damage. But it also causes a few problems, some of which have a pretty big (and possibly unintended) affect on fighters in Nova:
1. Only the swarm leader will fire missiles at normal ranges, the followers will only fire missiles when they get in range of the target ship, and even then the firing of missiles by the followers seems to be rare. This makes swarms of missile carrying fighters less powerful. In some cases such as the Fed Viper/Fed Anaconda swarms where a Viper is chosen to be the swarm leader, the Anacondas will never fire their missiles, which makes them overly expensive, slower, less powerful Vipers. Strangely enough the Phoenixes in a Firebird/ Phoenix seem to fire off their missiles, and I'm not really sure why.
2. The entire swarm system falls apart if the swarm leader is set to use its afterburner. Because following fighters in swarm mode don't use their afterburner (except maybe when they are in range of the target) the swarm leader zooms off leaving the rest of the swarm behind. This in itself causes a few very major problems
2a. The swarm leader will rush ahead and engage the target ship by itself, and typically the leader will be killed, since the rest of the swarm was left behind. When a swarm leader is killed a new leader is picked, and typically the swarm was far behind the first leader, thus the new leader rushes off and get killed. This cycle repeats itself, and what should be a fairly powerful swarm is reduced to a spread out string of single fighters engaging the enemy.
2b. Since the fighters following in swarm mode move towards the swarm leader, not the target ship you'll routinely see the swarm fighters fly parallel to or away from the target ship. This also sometime causes the swarm to fly big lazy circles around the target ship, instead of moving in to engage. And of course since the swarm routinely isn't engaging the target ship, the swarm leader takes all the fire, and dies quite quickly.
The end result is that nearly all fighter groups in the Nova scenario feel far less powerful than they should. There are two ways that this could be fixed, (hopefully) without doing too much work. Either the fighters following the leader should be allowed to use their afterburners so they keep up with the leader. Or, the leader should not be allowed to use its afterburner. In either case the following fighters should be allowed to use their secondary weapons normally instead of waiting till they are in range of the target ship.