Home » Stars! 2.6/7 » Stars! - Must Know » Known Bugs (JRC3) - Player Exploitable Bugs / "Features"
| Known Bugs (JRC3) - Coding bugs |
Thu, 16 March 2006 09:41   |
|
| Micha | 
 | |
Messages: 2342
Registered: November 2002
Location: Belgium GMT +1 | |
|
Link to the thread in the Academy
Known Bugs in Stars JRC3
Original document copied directly from Stars! FAQ
Split up in Coding Bugs and Player Exploitable Bugs / "Features" March 16 2006.
Coding Bugs
Race File Corruption:
If you edit the race name in a race file can cause the file to become corrupt. This is especially common when making the race name shorter than before. To get around this, when editing the race name, either edit it one letter at a time (saving and re-opening each time) or copy the race data into a new file by hand.
Random Race:
If at any point during the race creation you select random race but then de-select it, it can cause the race to generate a random race every time you use it to play a game with. This is because the random tag within the file is not unselected. Though it has been reported by others, I did a recent test of this, but could not activate it.
32k Ship Limit Per Fleet:
There is a limit of 32k of any one type of ship in a fleet (32,767 to be precise). If you try and merge two fleets together which would push the ship count over this limit (i.e. a fleet with 25k chaff and another with 10k), stars has a few problems. If done manually, the ship type will disappear from the fleet readout, but re-appear in the next generation (you will only lose ships in excess of the 32k). But if done using the "merge with fleet" waypoint order, all the ships of that type will disappear. This is because when the integer (16 bit - signed) holding the number of ships goes over the 32k limit it becomes negative, and as you can't have a negative number of ships, it reads as 0.
There are also some other limits in the game: 512 separate fleets, 512 separate minefields, 16 ship designs, 10 starbase designs, 256 tokens at a battle. The game will not allow you to exceed these limits.
AR Starter Colonies:
Starter colonies for AR races will not contribute excess resources to research, unless the build queue is cleared first (using the clear button) or the hull design changed / upgraded. This is due to the "build Starter Colony" order invisibly blocks the end of the queue despite the fact that it has already been completed.
Failing to Close to Range 2 with Sappers and R2 Beams:
In the battle VCR, if a token of ships armed is armed with both sappers and range 2 beams, and is facing an enemy token for which it has enough power in its sappers to completely take down its shields to 0dp in a single turn, then the ship will not attempt to move into range 2 in that turn even if it has spare movement points and regardless of the given battle orders (even with maximize damage). If the token lacks the sapper firepower to deplete all the shields then the token will close to range 2 as normal. The exact logic code-wise behind this bug has not been figured out yet.
Copy Protection Activates When Editing an Allies Turn File:
When you save an submit a turn and then transfer the .x file to another computer (which is being used by another player in the game) and then re-open the turn and then re-save and submit before finally turning over the file to the host, it can cause the copy protection to kick in. The solution is to open the turn file up, delete the .x file while stars is still running and then save and submit, the newly created .x file will be safe to send to the host for generation. The reason for this bug is that the machines hardware hash is only written to the .x file when the .x file is being created and not updated on subsequent save and submit, whereas the stars serial number is updated each time. When you open up your allies turn file, his hardware hash is already encoded into the .x file, but when you update the file with a new save and submit, your stars serial number is added to the file replacing his. Thus the host during generation sees the same serial number on two turn files but both with different hardware hashes. For more information, see the section on the Copy Protection Features.
Font Problems When Using a Non-English Version of Windows:
When playing stars on a non-english version of windows, there can be a few problems with fonts used in stars, the most noticeable of these is in the player scores dialog where the player names are written horizontally, making them overlap each other. This is due to the fact that Microsoft has used different filenames for the various fonts in each language version of windows. To solve this problem requires editing the stars.ini file in the windows directory and editing the [fonts] section. Details of the correct text for each language can be found here.
Netscape email attachment corruption :
Wen sending emails using Netscape, it will treat small attachments of an unknown file type as text (7bit byte) instead of binary (8bit byte) and so truncates the leading byte, this can lead to corruption of turn files sent this way. The solution is to tell it that the various stars file types should be sent MIME encoded.
"Stuck" bug
A fleet targetting a fleet and being targetted itself by another fleet with lower fleet# will not move. Fortunately this can not be exploited by players to interfere with fleet movements of another race. This bug will only affect your own race. (link to the thread in the Academy)
| m.a@stars wrote on Wed, 21 December 2005 11:53 |
- Let T be the Target fleet. Main pursuer would be M, and let's have some Secondary pursuer(s) S target the main pursuer. T can have a lower or higher fleet# than M, and it can be a foreign fleet or one of ours, stationary or moving.
- Next turn, if M has a fleet# lower than S, we find S has moved towards M, and M has moved towards T, as expected.
- If S has a fleet# lower than M, we find S has moved as expected, and M is still targeting its goal, but hasn't moved. It even shows in foreign scans as stationary: M is stuck for as long as at least one secondary fleet with lower fleet# is targeting it!
The golden rule to ensure your fleets obey their orders seems as simple as "first to move, lowest ID".
|
WP0 pop reload ignored
If:- a waypoint zero unload by hand of any of your population over an uninhabited planet is performed
- a waypoint zero dropdown command of "Colonize" is given to a fleet with a colonizer module present over that planet
- the population is reloaded by hand
Than: the reload order will be ignored and not saved with your turn. ALL pop will die (even the colonist that you did not unload) and the planet will remain uninhabited. A possible solution is to split the fleet into multiple fleets with cargo space and merge them back. If there is only one ship you'll have to redo your turn. (link to the thread in the Academy)
[Mod edit Mar. 08 2006: added "Stuck" bug]
[Mod edit Mar. 16 2006: topic split]
[Mod edit Mar. 14 2008: added "WP0 pop reload ignored" bug]
[Updated on: Thu, 13 March 2008 19:06] Report message to a moderator
|
|
|
|
Current Time: Thu Apr 25 11:54:29 EDT 2024
|
Members
Search
Help
Register
Login
Home
