Known Bugs

From Stars!wiki
Jump to: navigation, search

Player Exploitable Bugs / "Features"

The use of these bugs (with the exception of chaff), is generally considered cheating in multiplayer games unless specified previously by the host that they are allowed, though if you are in doubt check with your games host. Though it is still advisable for hosts to mention which things are disallowed before the start of the game.

Chaff

The game mechanics will cap the kills inflicted by missiles to the number of missiles fired (i.e. one missile = one kill). Also the targeting algorithm favours weakly armoured targets (in relation to cost in res and bor). These two facts can be taken advantage of. The cheapest armed ship you can build is a scout or frigate with an x-ray laser and QJ5 engine. If you build 1000's of these, the enemy's missiles will target these first. The problem is that the targeting algorithm doesn't take into consideration the fact that to kill a frigate with an Armageddon missile is actually wasting 1005 points of damage in overkill. So with enough chaff you can effectively nullify the enemies missile firepower. But note that the "one missile = one kill rule" doesn't apply to beams, so beamers will eat through chaff very quickly. See Art Lathrops article for a more in-depth description of chaff and the various tactics associated with it. Though most players consider this a perfectly legitimate and very useful tactic, there are an odd few players who consider this cheating, and so you will find the occasional game which bans chaff, though be very careful to get an exact definition (including ship designs) as to what is consider chaff from the host if it is banned (well before it becomes an issue), as the line between chaff and a cheap sweeper is very thin.

Split Fleet Dodge

  • (Sort of) Fixed in JRC4

An attacking fleet can only attack ships at the same location. If you split your fleet into many smaller individual fleets and diverge their movement orders, an attacking fleet can only engage one of them (the one with the largest mass will be targeted - though there may be a bug with this). A change was made in the JRC3 patch to stop multiple chasing fleets from all attacking the same target when this was done.

UR/CE Scrapping

Races with CE get half price engines, and races with UR get to reclaim up to 90% of resources and 70% of minerals that went into the ship/fleet. However when scrapping at another races starbase, Stars doesn't take into account the fact that CE races get half price engines and the resources given are based on the full amount. A ship that is mostly engine (scout with pricey engine), can be used between an alliance to generate "free" resources and minerals. This has been partially countered now that gifted or alien ship (i.e. not built by that race) are considered 30% cheaper in working out scrapping.

Battle Board Overload

The battle board can only handle a maximum of 256 tokens (shared among all races present). Excess tokens are simply left out of the battle. The tokens selected are based on fleet number, so the lowest numbered tokens would fight and the other left out, though each player is guaranteed (256 / players present) number of tokens. This can be taken advantage of by splitting off 256 chaff (or other cheap ship type), doing a split all on the 256 chaff fleet and then merging the rest of the fleet with the highest numbered ship. This would allow you to "dodge" the battle for the price of 256 chaff. Or simply keep some of more vulnerable ships out of battle (i.e. bombers and freighters). Most players would consider the deliberate use of this to be "cheating" unless specified by the host prior.

0.2% Minimum Damage

Stars records damage to armour in a fleet/stack as in 1/512ths (0.2%). Any shots in combat (that do armour damage) will be rounded up to the next 1/512th of the total armour in the stack. Normally this isn't an issue, but can be abused. By Building 100+ DDs or nubs with alpha/beta torps, and splitting them into individual fleets just before combat, you will fire a very large amount of slavos (100 fleets of nubs with 9 slots each with beta torps = 900 salvos). Normally these would only do a little bit of damage, but because they are all individual salvos they will each do 0.2% damage, and with 900 slavos that is 180% damage. Which would kill one enemy token/stack outright and damage another by 80%, and this is per round of shooting. The number of missiles per slot won't increase the damage, but having 2 or 3 in the slot will give you a second or third chance to make that salvo hit (missed missiles don't damage armour). Note that shields aren't calculated this way. And the 0.2% rule doesn't override the one missile = one kill rule, so when the stack is at 99% damage you will still need one missile per ship to do the killing blow. The best counter tactics for this are first to split up your fleet into several smaller tokens (thus it will only kill part of your fleet), and to have gatling armed beam ships (as they do damage to each token in range).

Blue Turbit noted:
Jeff McBride -Oct 4 2000, 2:00 am on r.g.c.s.:
This is *not* a bug and will not change for 2.7k. It is part of the architecture of the original Stars! battle engine. If you don't want 500 alpha torpedoes to be able to destroy 30,000 Nubians, don't put your 30,000 Nubians all in one fleet.

False Public Player Scores

Stars calculated actual resources during the middle of the generation, but calculates resources displayed in public player scores at the very end of the turn. This can be taken advantage of, by uploading pop from each of your planets using waypoint 1 orders (i.e. after movement) and then dropping them back as a waypoint 0 order (ie before movement). This doesn't affect actual output, but can significantly lower your reported resource output from which your score is largely based. This could prevent other players realizing that you are running away with the lead (and thus ganging up on you) until it is too late. Though this could backfire if you are caught, as other players would know that you are hiding something so may to gang up to stop you (which is exactly what you are trying to prevent).

North/South Minefield Immunity

  • NOT Fixed in JRC4

There is an unusual bug in which there are no minefield hit checks done do a fleet traveling exactly due north or due south. Though the checks are carried out if there is even 1ly of east/west movement. This could allow a player to travel through a minefield at warp 10 with a 0% chance of hitting a mine. Most players would consider deliberate use of this bug to be "cheating".[1]

East/West Speed Bump Minefield Immunity

  • (Sort of) Fixed in JRC4

A similar bug to the one above, but this time affecting only speed bump fields for fleet traveling due East or West.

SS Pop Steal

  • Fixed in JRC4

The robber baron scanner can steal minerals from an enemy player, though a player cannot usually steal enemy colonists. Though in the J patch, the check for seeing if the player wishes to steal enemy colonists was disabled when using the waypoint 1 task option (Transport|colonists|load all). This was not intended. This bug has been proved to unbalance the game when used. Most if not all players would consider use of this bug to be very serious "cheating" unless "specifically" stated by the host prior the start of the game.

JRC4 Fix caveat: Mineral transfers done by waypoint task must be set by hand. They will not happen if using the standard zip orders because those orders include grabbing all pop as well.

[freepop] Hack

Using a memory editing utility it is possible to create colonists out of thin air, limited only by a players freighter capacity, with the help of a memory editor. This abuses a lack of a viability check for loading colonist from an uninhabited planet, usually you cannot load more colonists than you drop down in a turn, but a memory editor can be used to trick the user interface into believing that you had dropped down millions of colonists, and the host doesn't double check these figures. Use of this in a multiplayer game would be considered by most players to be a totally inexcusable cheating offence.

Cheap Starbase

If you build an EMPTY starbase on a planet which has no base yet, and finish it to 99%, then next turn you can still EDIT the design, add all the weap and armor you like, and the base is still 99% finished. This means you only pay 1% of the full armed base, and 99% for the empty base. It appears that if you don't exit the Ship builder that you can delete the empty fort design (99% built) and create a fully kitted out UltraStation, since the partially built hull isn't deleted from the planet until after the ship builder is closed - and when you close it there is still a hull in that slot...

Mineral Upload

Stars! allows you to upload minerals to any fleet in orbit that does not belong to you. You can even do this if that fleet does not have a cargo hold. This causes the minerals to "disappear". People have abused this bug to deny the salvage of a battle from their enemy by uploading the minerals from the surface to the enemies warfleet/bombers.

Target List Overload

The fleet lists that popup when you right click in the scanner pane and the blue diamond of the waypoint tile will only list 100 fleets. So when someone has 101+ fleets at the same coordinates (in orbit of a planet for instance) you can NOT target fleet 101 or higher (these are the fleets with the highest fleet #s.) You can use the "Other fleets here" list to select (but only view) the higher fleets.

Space Dock Armor slot Buffer Overflow

If your race has ISB and RS, building a Space Dock with more than 21 SuperLat in the Armor slot will result in some sort of error. 21 SuperLat gives a Space Dock 16,000 armor, 22 SuperLat gives it 49,518 Armor. For a full 24 SuperLat stack, you get a whopping 51,018 armor. In comparison, a Death Star for an RS AR tops out at 31,500 armor (not including M.T. toys). {quote Matt Laub} Race has to have the RS LRT and starbase hull has to be Space Dock to trigger this bug. More details here at HWF.

ISB trumps IT gate scanning

Improved Starbases makes gates invisible to some IT gate scanning. Normally an IT gate will provide planetary and starbase information, although not fleet details, of any planet with a gate in range. This is a limited pen scanning on enemy worlds, and is subject to SB cloaking. IT planets using 150kT/600ly or infinite/800ly gates will not scan any gate, on any hull, owned by a race with the ISB LRT. Other IT gates scan correctly, and the gates of races without ISB can be scanned as normal by the above IT gates.

This may seem like a limited liability, however, there is often a fairly long period where infinite/800ly gates are the best that can be built, before the 100ly/infinite or infinite/infinite gates can be built. {quote LEit} Note that the other race only needs the ISB LRT, they do not have to build a Space Dock or an Ultra Station to make their gate invisible, any hull will do.

Starbase Friendly Fire

In battles where a starbase is present, the player owning the starbase can change the "attack who" in his default battle orders to make friends fire upon eachother. (There was already a brief note about it in the Starsbase FAQ but this thread at HWF promoted this to a bug.)

Latest bug description by Ptolemy:

Ptolemy wrote on Tue, 22 November 2005 20:14
OK here is the definitive description of this bug;
I have now completed a series of major tests for this problem and this bug triggers only in one specific circumstance and the bug works like this:
1. The default orders for the defender must be set to attack any of the attacking players specifically.
2. The highest attacking player number will attack his ally with the lowest player number. If there are 3 or more allies attacking only 2 of them will shoot at each other. The highest and lowest player numbers. This is not an absolute guarantee since battle sims would need to be done with 7 or 8 players to check the effects.
Note: I have had difficulties in getting a 5th race into the battle at times - the turn generates and a ship that should have been in the battle is in orbit but was not included in the battle.
Note 2: From the original tests done with low powered ships some false results were seen. Using later tech, higher speed ships the problem occurrs in all cases - with or without defending ships. I serioussly recommend that the setting of default battle orders to attack a specific player in order to get allied ships to kill each other be listed as a known cheat.
The effect with 3 or more allies when the defender default orders are set to attack everyone is slightly different in that it results in a free for all with all ships trying to kill each other.
Ptolemy

Repair after gating loophole

The help file states that a fleet does not get any repair in the year it travels by gate. However there is a loophole.

In the Stars! Order of Events you'll see that the WP1 merge order is carried out *before* repair. This leads to the following: when you gate a fleet# A and give it a WP1 merge order at the destination with a stationary fleet# B the damaged ships in fleet# A (damage either from previous battles or from overgating) *will* get repaired. Stars! looks for fleet#s that have moved and obviously fleet# A no longer exists.

The repair % depends on the normal rules: does the planet has a dock, does the fleet you merge into holds a SFX etc and of course if you have a battle at the planet where the fleet is gating to there will be *no* repair. (thread in the Academy at HWF)

Mine Damage Dodge

If you have two different ships in one fleet, the first one in your design pool will take 4/5 of the damage, and the second one will take 1/5. {quote LEit} You can (ab)use this to for example give your DD sweepers a longer life span. Pairing one (shielded) DD with a chaff (with the chaff in a design slot somewhere above the DD) makes sure the DD will survive a hit from a standard minefield with minimum damage (1/5). To achieve this otherwise you would need to use 5 of such DDs in one fleet. (thread in the Academy at HWF) (old r.g.c.s thread)

Mine Damage Allocation

Same process as Mine Damage Dodge but where a player still takes the full amount of damage, merely controlling how the damage is allocated. eg Using a high-armour ship that will survive the mine hit to soak up damage rather than using a chaff that will die receiving much more damage than is needed to kill it. (post in the Academy at HWF)

Exploding Minefield Dodge

The SD specific mini-minelayer and super-minelayer hulls are immune to the explosions of their own minefields however the checks are performed in player number order and, regardless of number of detonating minefields the ship's in, it can be hit only by one field hence the rest of the exploding minefields are ignored. I.e. if a given MML or SML has "survived" its own exploding field, it will also survive the exploding fields of all following SD players' exploding fields it may be in. (thread in the Academy at HWF)

Colonization Module Check

Copies of ships with a colonisation module removed and the slot left empty can still colonise planets. (thread in the Academy at HWF)

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

When 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. A new old bug by m.a@stars:

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:

  1. a waypoint zero unload by hand of any of your population over an uninhabited planet is performed
  2. a waypoint zero dropdown command of "Colonize" is given to a fleet with a colonizer module present over that planet
  3. the population is reloaded by hand

Then: 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.

Crash Stars Bug

When Player 1's fleet 1 is at a planet with a starbase other than an orbital fort and the final player has a starbase design occupying his 10th starbase design slot stars can crash, the exact circumstances that cause the crash still need to be figured out since something else seems to also be required for the crash to happen but the above circumstances do need to occur for the crash to take place. Ways to avoid the crash are for a dummy race to be placed in the final slot so the 10th starbase slot is never used, for player 1 to keep his fleet 1 away from planets and for it not to be destroyed either in a battle or in a minefield or to have an experienced player as the final player and for them not to use the 10th starbase slot.

Shields are displayed incorrectly in VCR

The VCR displays ALL shields according to your own RS setting and does not account for whether or not foreign ships have RS. This bug only affects the display, not the result calculations.

Kotk wrote on Tue, 23 November 2004 01:07
If something had shields and you killed it, you should know for sure if it had RS or no by damage done.
The damage done is displayed correctly.
Armor damage % is also displayed correctly.
If you have RS or no, dont look at the numbers it say about shields left, these are almost always wrong.
  • and more recently Micha wrote on Mon, 9 March 2009
    The race *with* RS saw the correct shield values during the entire battle. The race *without* RS saw the correct shield values in the first round but in the second round the RS race was showing non-RS values.

Cosmetic Bugs

Battle VCR point of view

The battle VCR displays the battle from the viewpoint of your Race - they will appear to have your race's PRT and LRT abilities. This has a number of misleading effects:

  • If you have Regenerating Shields then your battle VCR will display their shield rating as if it where RS (as well as their Armor) and vice versa.
    • This includes the displayed damage calculations - their non-RS shields will be depleted(and sappers will stop targetting them) even though it says they haven't.
  • If you are playing a SS it will say they have the inherent 75% cloak regardless of their PRT
  • If you are playing a JOAT it will say they have a scanner even though they doesn't.
  • others?

(source post at HWF)

Credit

Original document copied from Stars! FAQ via this thread on HWF

See Also