Old Bugs and Behaviors

The Classic difficulty mode of the current version of Project: Starfighter copies the behavior of version 1.1 of the game (the last version released by Parallel Realities) as exactly as possible. However, fixes for some old bugs have intentionally been retained even in Classic difficulty, and some behaviors have been made to resemble the behavior of the modern difficulty modes. As such, this page documents all bugs and behaviors in version 1.1 that have not been implemented in Classic difficulty exactly as in version 1.1, and why they have been changed. Entries are sorted roughly by the time that they become relevant in the game.

Bugs That Did Get Implemented

Although as described below there were bugs we opted to fix for even Classic difficulty, there were also bugs we specifically endeavored to simulate:

Flying against the edge of the screen slowed the player down compared to flying away from the edge because the speed the player moves across the screen wasn't used to increase the camera scroll speed. This is retained for Classic difficulty because it causes running away from Kline to be more difficult and also because it causes scrolling segments to be sort of "boxed in" much like a normal scrolling shooter, and so fixing this bug would cause Classic difficulty to feel substantially different from the original.
If you had collected a Super Charge and then collected a regular powerup, the feature the powerup would upgrade got set to your normal maximum, effectively downgrading it to that. This is retained for Classic difficulty because it serves an important balancing purpose; without this, the Super Charge can be retained indefinitely with little effort or consequence.
When a Charge Cannon blast hit something, its "life" (time before it dissipates) reduced rather than its damage, effectively multiplying the damage of the Charge Cannon by the number of times it could collide with a target and also allowing it to sometimes pass through a ship it didn't kill. This is retained for Classic difficulty because to change it to the more balanced approach would substantially reduce its effectiveness and therefore not be true to the experience of the original.

Spirit Instant Travel

Project: Starfighter 1.1 treated Spirit as a special system: instead of clicking on a planet causing a travel button to appear, you simply instantly teleported to the given planet. This behavior was not kept in Classic difficulty; instead, travel on Spirit works as it does in Sol after completing the Earth mission (i.e. you still click on the travel button, but there is no risk of interceptions and the travel progress bar's duration is always short). The reason for keeping this change in Classic difficulty is simply because it keeps the interface more consistent while having the same gameplay effect (no danger from travel).

Shop Price Bug

In Project: Starfighter 1.1, the amount of money the "Buy" and "Sell" buttons take from you or give you is based on the currently displayed item and price; when buying, you lose the currently displayed price, and when selling, you gain half of the currently displayed price. This effectively means that, for upgrades, you actually sell the item at half the price of the next stage of the item. This meant that selling the highest stage of any item would get you nothing; there was no next item, and the memory location pointed to for price info was set to 0, which the code then displayed as "N/A".

More significantly, though, it also was exploitable. Most notably, the Plasma Cooling Booster Stage 2 was bought for $2000, but sold for $3000 (half the price of the Plasma Cooling Booster Stage 3, which was $6000). This meant you could effectively gain money by constantly buying and selling the Plasma Cooling Booster Stage 2.

This is not implemented in Classic difficulty because it effectively just serves as an unofficial infinite money cheat and is clearly unintended behavior caused by a bug. While having an infinite money cheat is nice, there is already the officially supported infinite money cheat available via the standard "humans do it better" cheat options, so the unintended infinite money cheat caused by the buggy shop behavior is therefore redundant. The possibility of getting nothing back for selling an item is also potentially frustrating. Therefore, Classic difficulty instead implements what was likely the original intention: selling items at half the price they can be bought at.

Zero Rockets

Project: Starfighter 1.1 allows you to sell your first Rocket Pod (the one which brings your ammunition up from 0 to 5). This first Rocket Pod had a defined price of $0, but because of the shop price bug, you were able to sell it for half the price of a second Rocket Pod; the second Rocket Pod cost $125, so that meant you got $62. Classic difficulty does not allow selling the first Rocket Pod simply because there is no benefit to doing so; with the shop bug fixed, you can't get any money from selling it. All that would happen is you would be unable to get rocket ammunition until you re-bought the Rocket Pod (again, for $0). As such, the game simply doesn't allow you to have less than one Rocket Pod.

Plasma Overflow

In Project: Starfighter 1.1, it was sometimes possible for the amount of plasma you had to overflow; for instance, if you had 240 plasma and gained 40, the amount of plasma you had would "increase" to 25, i.e. you would lose nearly all your ammo. This rather annoying bug was caused by the fact that the amount of ammo you had was stored in an unsigned char type variable, meaning it was 8 bits. The current version of Project: Starfighter instead uses the standard int type (which is guaranteed by C to be at least 16-bit), so there is no chance of overflow with numbers as small as 250. The bug is not simulated in Classic difficulty because there's no reason anyone would want to lose ammo, and so fixing this particular bug is clearly a positive.

Vanishing Target

Project: Starfighter 1.1 made the targeting arrow vanish when a radio message (e.g. Phoebe or Ursula bragging or yelling at you) appeared. The reason for this behavior was simply that the game placed the radio message boxes and the targeting arrow in the same place, and so showing them both at the same time would have looked ugly. The current version of Project: Starfighter has many more radio messages than version 1.1 did, including brag messages from Chris Bainfield, so repeating this behavior in Classic difficulty would be rather annoying. Instead, the targeting arrow is moved further down so that it's below radio messages when they display and therefore doesn't have to shut off when a radio message appears.

Insta-Warp

In Project: Starfighter 1.1, when an enemy ship ran away (such as at the end of the first battle with Kline), it immediately started moving at full speed. This at a glance doesn't seem like a bug, but as it turns out, it was. Version 1.1 of Project: Starfighter had code which was designed to slowly accelerate these ships up to their eventual maximum speed. However, the maximum speed they were being brought up to was a negative number while the minimum speed they started at was zero, i.e. the maximum used was what should have instead been the minimum. The reversal of arguments meant that, with the code used at the time, the defined maximum value was chosen, effectively canceling out the intended acceleration effect. Due to the presence of this buggy code which suggests that the acceleration effect was always the intent, Classic difficulty retains the fix for this bug.

Uncounted Progress

Project: Starfighter 1.1 had a bug where if you rescued slaves for the Eyananth slave rescue mission after the interception was destroyed, the rescued slaves would not count toward the mission. The fix for this bug is kept in Classic difficulty because it's very frustrating to deal with and carries no benefit.

Odeon Phantom Message

In Project: Starfighter 1.1, during the Odeon mission (where you have to fight and rescue Ursula), Sid Wilson will at some point say, "Chris!! Ursula's running away!" This is then followed by a strange message saying "128". If you were unlucky, you may have also at this time noticed a random enemy becoming invincible, forcing you to finish the mission without completing the secondary objective.

This whole behavior was a result of a script bug. Originally, things like dialogs and special events in missions were handled by "script" text files. They were in a pretty simple format which consisted of a series of time-based events. They listed as parameters the time of the event in seconds, the "face" (character portrait) to use, the "entity" (ship) to affect, the flag to set to the entity, and the message to show. These were not always specified, and so there were special values that indicated "none" for most of these. As an example, the portion of the script which caused Krass Tyler to run away in the Almartha mission read as follows:

150 FACE_KRASS 19 128 I've earned my fee. I'll see you around, boy!

This event happens 150 seconds from the start of the mission. It gives entity 19 (which is Krass Tyler's ship in the Almartha mission) the flag "128" (which was the flag for making a ship run away), and shows a dialog box with the Krass portrait which says, "I've earned my fee. I'll see you around, boy!"

The script event in the Odeon mission which causes the strange message, on the other hand, reads as follows:

195 -1 0 14 128

Here, again, 195 is the time of the event, and -1 indicates that no character portrait is to be used. But then we have an extra "0" argument before what should be the third argument; "14" corresponded to the Ursula ship in this mission, and if you recall from the Almartha example, "128" is the flag which would cause a ship to run away. So clearly, what this script is trying to do is make Ursula run away, just as Sid Wilson said. But because of that extra "0" argument, it instead gives entity 0 the flag "14". Now, entity 0 is one of the nine regular ship entity indexes, so it will point to a random enemy ship (whichever one happened to be assigned to index 0). "14", as it turns out, it a mix of the flags which cause friendliness, invincibility, and being disabled. Lastly, the "128" becomes text for the message, which is printed as narration (in a black box with no portrait) due to the fact that no character portrait was defined.

So as it turns out, this was quite the catastrophic scripting bug, and it's the source of that strange "128" message. It's very likely that what was intended to be here in the script was this:

195 -1 14 128 @none@

Had the event looked like this instead, it would have worked as intended. This was probably intended to cause a fail condition; if so, it would have worked exactly like the Moebo mission with the Star Killer, except probably without the "explosion" effect. I say "probably" because, as it turns out, there's no code in the game to actually handle Ursula running away in this mission, so if the script had actually worked as intended, it would have just caused the mission to get stuck in an unwinnable state (as without the Ursula ship, you can't complete or fail your primary objectives).

It is our speculation that the reason for this weirdness is probably because the original developer decided against the fail condition before doing any proper testing and simply never noticed or remembered that the event was still there. It must then have just been fortunate happenstance that the event was broken and in fact always either did nothing or just made it impossible to destroy one of the enemy ships (forcing you to fail the secondary objective).

In any case, since the behavior was a strange, potentially frustrating bug which seems to have been an artifact of the game's development history, Classic difficulty does not implement this weirdness.

Missile Limit Breach Bug

The way Project: Starfighter 1.1 checked to see if you were over a weapon's "ammunition limit" was a bit different than it is in the current version of the game. Rather than limiting the number of Rocket Pods your ship was allowed to carry, ammunition limit of homing missiles was implemented separately and only enforced in the shop, and only if you had exactly the defined ammunition limit. This meant that you could get more than the limit (20 missiles for regular homing missiles, or 10 for the double or micro homing missiles) from missions. Then, you could buy them as much as you wanted. The fact that even the shop restrictions failed to work after you had done this (caused by code that assumes you'll never go over the ammunition limit) tells us that this was clearly an oversight, rather than intentional behavior, and as such it is not reimplemented for Classic difficulty.