It looks like I'm finally almost done with this! The only thing left
is gradually replacing "Starfighter.h" imports with imports of what
actually is needed.
I did one structural change to the way ship_fireBullet works. It
previously had two separate places for reducing ammo from the player.
I changed this so that it removes ammo in the same place regardless
of which weapon it is, but then performs the plasma "out of ammo"
action afterwards. It seems to work properly.
Also fixed a flaw in the saving which would in some cases cause
the stationed planet to not get saved properly.
This was done with "replace all" actions, but I have checked and
the only collatoral damage has been to capitalize some instances
of "objective" in comments.
At first I was doing the same thing to them I did to the bragging
messages, but when it came to actually thinking of things these
characters should say, nothing I liked came up. The main problem
is nothing fits the characters' expressions. Add to that the
complexity of making this really work right, and it's just not
worth it.
The Sid death message has also been removed, both for consistency
and because of the mismatch of Chris's face with what he said there.
The explosions of mines off in the distance are extremely annoying in
the Mars mission, in particular. There's no real point in them
doing a timed off-screen explosion, anyway; if they just disappear,
the player won't notice.
This was just really weird-looking and had no particular benefit.
I guess theoretically you can use the couple of seconds to grab stuff
you missed, but in practice, there usually isn't much stuff there.
Sure, the escort is what you're supposedly after, but it's
invincible, and your real priority is to protect Sid. It helps that
it now says "Sid" when Sid is the target; that should prevent
any possible confusion. :)
There were two problems:
1. Some areas did not have any code to protect against this.
2. In one area that did have such code, it was malformed, and actually
caused the "no damage" cheat to be negated after the mission was
completed.
Both have been fixed.
The previous one positioned the arrows based on the difference between
their X distance and Y distance; objects that were further away
would be closer to the center. However, the code was confusing, and
a major practical effect of this was it was impossible to really know
exactly where an object was.
This new, simpler method makes aiming at targets that are off-screen
feasible, and it also utilizes the diagonal arrows.
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.
onpon4