It was triggered whenever there was a message being displayed.
Thing is, there's no legitimate reason to do this. It doesn't ever
obscure the radio message, and there wasn't some technical limitation
in place. It just did it... just because.
This was a strange cause, and I wonder why it happened. Quite simply,
there was an assumption in the code that any alien's primary weapon
was a bullet, despite the fact that the secondary weapon code could
handle any weapon, including bullets. I've fixed this by getting rid
of the special primary weapon mechanism; the one for the secondary
weapons is used on primary weapons as well.
There are two aspects to this:
1. They now simply make sure your plasma ammo is at a minimum of
50, rather than adding to your plasma ammo as in the other
difficulties.
2. Added a simulation of a bug in Starfighter 1.1 which caused
each aspect of the Supercharge to be lost when you picked up
a different associated powerup. Even though this was a bug,
without it, the Supercharge becomes extraordinarily more
game-breaking, since it's the only thing that sort of limits
its longevity.
This should add some much-needed depth to the tacticality of the
weapon. It's not much: it takes 5 plasma cells to fully charge the
cannon. But it does eliminate the previous effect where the charger
was always preferable over plasma bullets; it's still preferable in
a lot of circumstances, but for smaller ships, it's now typically
better to use plain old plasma ammo. It also limits the amount of
times the charger can be used.
The only magic numbers left now are related to positioning, image
sizing, and the remaining "data" files (the "planets" and "brief" ones).
At least, I'm pretty sure that's the case.
God, this one was definitely the biggest headache of all of the
magic number erasing. Never did I expect such cryptic problems.
The first problem was that the entirety of the player's weapon
struct was a part of the save file, *including the weapon's "image
indexes"*. Since the indexes have been changed, and the originally
used one is now unavailable when it's requested, this was causing
a segfault later on. Had to fix this by setting the image index
when the game is loaded.
The second problem was related to another bug I've been confused
about for years: the one that causes mobile rays to fire 5 green
shots. The entire reason those shots were green was because
the weapon's image indexes were undefined, and *that was causing
them to default to 0*. 0 was simply the index of green plasma.
Of course, though, now attempting to use that image causes a
segfault, so for now, I've fixed this by changing the image index
of the mobile rays to the red plasma bolts.
There are still some magic numbers left, related to the intermission
screen. But the hardest part is now done, thank God.
This is capable of handling any resolution which is at least 640x360.
Actually, resolutions a bit smaller than that can be handled. No
manual adjustment is necessary. :)
Now, the intermission screen needs to be fixed...
Also, now that the magic numbers are gone, I was able to get rid of
all the hardsetting of numbers for the special ship indexes (which
was only in place to avoid breaking the magic numbers).
Like "scripts", these definitions in text files make absolutely no
sense. They are completely unreadable, and Starfighter's engine is
inflexible anyway.
I'm going to do this for all of the stuff in the "data" directory.
It was obviously an attempt to make Starfighter more flexible
somehow, but it fails at that entirely. More importantly, these
things are both unreadable and easy to make mistakes on. Simple
C code is much easier to read.
The only disadvantage is that recompiling is now needed to change
the "scripts", but considering that they had hidden limits and
no one was making custom missions to begin with, I don't consider
this to be a real loss.
I rewrote the method because what it was doing was so confusing, I
couldn't figure out whether it actually worked right or not. I think
it did, and it's only 2/3 of a milllisecond anyway (not noticeable
at all), but this new way of writing it is much clearer.
The fourth is simply a duplicate of ship_collision for bullets. A
bit redundant, but I figure it's clearer of a definition. Besides,
this opens up the door to possibly making bullets a different struct
type in the future, if that turns out to be desirable.
The idea is clearly supposed to be breaking the boss in two and then
destroying the halves, so it makes no sense for the wings you break
off to also act as shields, which they did. Pretty much all this did
was cause a lot of shots to be wasted.
I don't really understand why this code was implemented only for the
boss and not for anyone else. My only guess is it was designed to make
the level harder by letting enemies fire backwards while you can't,
but mine-droppers can already effectively do that.
The primary reason I decided to make sure they all face forward is I
was finding it to be nearly impossible to get through this level in
Nightmare difficulty; those ships being able to shoot backwards is
a HUGE advantage, because it's almost impossible to position yourself
in an area that's safe.
It may be that the unfair previous behavior was put in to compensate
for the AI's frankly asinine movement pattern. The random movement is
fine most places, but here, it's blatantly obvious that it's random,
and the enemy ships pay a steep price for it. What the ships should
be doing is positioning themselves so that they end up shooting or
dropping mines at the player. But the boss itself also has such a
positioning problem anyway; that should be properly fixed in the
future, so I might as well do the same for the smaller ships when
that time comes.
I honestly don't understand why these cheats were here. Preventing
enemies from moving breaks some missions and doesn't do anything
useful, and preventing enemies from firing is basically no better
than the invincibility cheat (and might even be worse, if it applies
to Sid; I didn't check).
The way it was previously, you always knew exactly where the WEAPCO
scientist was. I don't remember if this was the case in the original
game (I don't think it was), but regardless, this makes the mission
seem incredibly short and easy, and it ends up centering on the
secondary objective rather than the primary objective. Now, you have
to search through all the asteroids until you find the right one,
and you have to pay close attention to explosions. Collecting ore is
just something you do along the way.
It may be fake difficulty, but after all, tropes are not bad.
The bug in question caused the super charge to be stripped away when
you collected powerups; each powerup would limit that aspect of your
weapon to its maximum. This put a limit on how long you could keep the
super charge, so I've added it back in for "original" difficulty.
onpon4