Current the AI always selects capital+ weapons vs big/huge ships. This
makes the AI take shields into accounts, and not use the weapon if
either the shields are still up, or the weapon isn't good vs shields.
I don't greatly like the magic number 1.33 to determine if a weapon is
good vs shields, I'm happy to take alternative suggestions. I have
checked DE, WoD & BP tables and I don't think this change will affect
any of them (picked them because their either use capital+ weapons or
have shielded capships)
There's one DE weapon that the AI won't select anymore while shields
are up; however its fluff says it's bad vs shields and suggests a
paired shield-breaker so think it should be OK.
The core bug fixed here is #1982. After ship_create sets up the ship, parse_object_create_sub does further initialization by copying some values from the parse object. In most cases there are sensible defaults, but a few special cases require some post-processing...
- ship sounds
- the new way of initializing warp effects to allow per-ship customization
- intrinsic-no-shields
- an arrival entry in the mission log
- script hooks
I also took a further look at normal ship creation and tweaked some things...
- initialize ai mode in ai_object_init
- remove redundant assigment of ship name from parse_object_create_sub (it's also done in ship_create)
- remove redundant goal clearing from parse_object_create_sub (it's also done in ai_clear_ship_goals via ship_create)
- avoid overwriting the initial ai mode if the fix-ai-class-bug flag is set
- make the code slightly more efficient by not redundantly setting flags while searching for subsystems
1. Removes unused parameter
2. Applies 'static' keyword to the routine.
Together, these two changes should help the compiler generate
more efficient code.
Signed-off-by: Peter Mitsis <[email protected]>
Removes two unused parameters from ai_ship_hit(). Instances where this
routine are called are also updated.
This should result in slightly more efficient code.
Signed-off-by: Peter Mitsis <[email protected]>
Removes the unused parameter from the routine. This has a small
ripple effect such that it results in an unused parameter in one
of the routines from which it is called.
Signed-off-by: Peter Mitsis <[email protected]>
1. Removes unused parameter
2. Applies the 'static' keyword to the routine.
Together, these two changes should help the compiler generate slightly
more efficient code.
Signed-off-by: Peter Mitsis <[email protected]>
1. Removes unused parameter
2. Applies 'static' keyword to the routine
Together, these two changes should help the compiler generate slightly
more efficient code.
Signed-off-by: Peter Mitsis <[email protected]>
1. Removes an unused parameter.
2. Applies the 'static' keyword to the routine.
3. Applies the 'const' keyword to the remaining parameter.
Together these changes should help the compiler generate slightly more
efficient code.
Signed-off-by: Peter Mitsis <[email protected]>
Applies the 'static' keyword to the routine as it is only used in the
module in which it is defined.
Removes an unused parameter.
Together, these two changes should help the compiler generate slightly
more efficient code.
Signed-off-by: Peter Mitsis <[email protected]>
Adds the 'static' keyword to the routine as it is only used in the
module in which it is defined.
Removes its unused parameter (and updates location where it is called).
Signed-off-by: Peter Mitsis <[email protected]>
Removes the unused parameter from the routine and adds the 'static'
keyword to the routine as it is only used in the module in which it
is defined.
Signed-off-by: Peter Mitsis <[email protected]>
This routine is only used in the module in which it is defined, so the
'static' keyword has been applied to it.
One of its three parameters was unused, so it has been removed.
Finally, the 'const' keyword has been applied to appropriate arguments.
These changes should help the compiler generate slightly more efficient
code.
Signed-off-by: Peter Mitsis <[email protected]>
The routine ai_turn_towards_vector() had an unused parameter (frametime)
and it has been removed.
Each of the instances where this routine is called have also been updated
to reflect the parameter removal. As this resulted in the routine
swarm_update_direction() suddenly having an unused parameter, that routine
and the places where it is called have also been updated (remove
unused parameter).
Signed-off-by: Peter Mitsis <[email protected]>
Removes the unused parameter from ai_big_maybe_enter_strafe_mode().
Each place where this routine is called has been corrected to reflect
the updated API.
The 'const' keyword has been applied to remaining parameters as
necessary.
Signed-off-by: Peter Mitsis <[email protected]>
The routine ai_big_ship() is empty, and appears to have been since it
was initially added many years ago. Removing it helps eliminate some
unused code.
Signed-off-by: Peter Mitsis <[email protected]>
By enabling the "$Use Actual Primary Range:" profile flag (which can also be set on a per-AI-class basis), the code to determine if the AI should fire its primary weapons will not only perform its current "range based on speed of weapon and target" calculation, but it will also compute the weapon's actual range and not fire if the target is outside of it.
This can be used for mark parts of the code which should be unreachable
in normal execution. In debug mode, if such a statement is reached an
Error dialog is shown which aborts the execution. In release mode the
macro is replaced with a compiler specific expression that lets the
compiler know that this part is unreachable which allows it to optimize
the code better.
This adds a new class which allows to create type safe resource handle
types. At the moment, the engine uses ints pretty much everywhere for
providing handles to resources created by the specific subsystems. Since
all ints are the same to the C/C++ typesystem it is perfectly legal to
pass a sound handle to the graphics API as a buffer handle which will
obviously cause issues.
This adds a new type called "ID" which is a wrapper class for a generic
handle but with added type safety. An instance of this class cannot be
passed to a function expecting another type of handle which provided
compile-time type safety for these APIs.
As an initial test I converted the game sound handles to this new type.
I already found a bug in the mainhall system thanks to this new type.
The mainhall used the game sound handles as sound instance handles which
probably meant that that specific code never really worked right. I
removed the code since there was no better alternative for fixing it.
Before, if any parsing call failed it would throw an exception which
would have been propagated to the exception handler in main() which
terminates the program. This should fix that.
Upgrades and deprecates the original jettison-cargo-delay sexp by removing the unused delay parameter and adding a new parameter to control the speed of jettisoning. It further fixes the physics calculations by using the dockpoint normal instead of the vector between the center of the host ship to the center of the cargo.
See also the thread on HLP: http://www.hard-light.net/forums/index.php?topic=92844.0
FSCyborg