I have added a conditional to the code so that if the player
tries to lock onto the 2nd star and they are very far away, >1e8,
then the game will not allow the star to be locked.
This is a temporary workaround since if a distance of farther
then this is attempted then the view will be throw way off
and the stars will not be shown locking onto correctly.
I've also made the locking functions return booleans so I can
determine the success of the lockings.
This is a partial fix for #9961.
The code was preventing the position and view from changing
when the distance between the current and new position for
a marked auto mover was zero. This happens if you lock the
2nd or 3rd star and then unlock and relock again.
It was prevented this with asserts and if statement checks
and I removed them all.
This section of code isn't doing any inverses based on the
reciprocal of the distance so theres no issue with allowing
transition speeds/distances of zero.
Fixes#10148.
This allows MemoryReadWriteStream to be passed successfully to
functions that use the SeekableReadStream type so that they can
call the `pos` method, like the DPCMStream class of the VMD
decoder.
The original check was incorrectly disabled for IHNM in commit
ab6fb8e9c3. The check has been enabled again, with an added condition
for actors that can be used, like the jukebox in Gorrister's
This has been added in commit 5624ba23d0 and is no longer needed.
The gem is shown correctly over the compact disk in that scene,
and the behavior is the same as the original
When you dispense a chicken, but don't pick it up and leave, the
chicken is returned to the dispensor. But previously you couldn't
then get another chicken, though you should be able to get one.
Originally, if you unlocked a star when you had 2 or 3 stars
locked and then relocked without changing views then the game
crashed.
This was because it was trying to transition a distance of zero
and this failed an assert (to normalize the length to be the distance).
The transition is no longer done so the crash does not happen.
Fixes#10147.
We get this warning a lot for the Singleton class due to the way
we instantiate its specializations. Also in case we forget the
instantiation we get a link error anyway, so the warning is not
very useful anyway.
If you want to remove locked stars you can do so using the D key,
but previously, you could also deselect a currently locked star
via the skymap and it would crash.
It previously crashed if:
1. You had 2 stars locked on and you tried to remove the 1st
2. Had 1 locked and 1 unlocked and you tried to unlock the 1st
3. Had 2 locked and 1 unlocked and you tried to unlock any of
the other two locked stars.
Refactoring would allow quicker comprehension of the logic of
this section of code.
Fixes#10126.
This involved removing header files and forward declaring when possible.
I also reorded the header include files to be local to gloabal.
E.x., in the class implementation the class header file
would be the first included.
This is a first pass of header reduction for star_control/ files
Eugene Sandulenko
Simei Yin
David Fioramonti
Paul Gilbert
Colin Snover
Filippos Karapetis
Bastien Bouclet
Thierry Crozat
Ben Castricum