Difference between revisions of "Bugs connus"

Revision as of 17:11, 18 June 2009

Bugs exploitables par les joueurs / Caractéristiques spéciales du jeu

L'utilisation des bugs suivant (à l'exeption des "leurres") est généralement considéré comme de la triche lorsque utilisé dans des parties multijoueurs, à moin d'avoir été préalablement autorisé par l'hôte. Il est toujours préférable, en cas de doute, de vérifier avec votre hôte pour être sur qu'un bug est accepté ou non avant de l'utiliser en cours de partie. Il est aussi fortement recommendé que les hôtes mentionnent quel bugs sont permis ou refusé avant le début de leurs partie.

Leurre (Chaff)

La mécanique de combat maximise toujours les destructions de vaisseaux en relation avec le nombre de missiles lancés (ce qui veux dire: maximum de un vaisseau détruit par missile). L'algorithme d'acquisition de cible donne aussi la priorité aux cibles avec un total de point d'armure faible (en relation avec le coût de ressources et de boranium). Il est possible de prendre avantage de ces deux faits de la manière suivante: le type de vaisseaux le moin onéreux à construire est soit un scout ou une frégate avec un laser x-ray et un moteur QJ5. Si vous construisez un certain nombre de ces vaisseaux et les lancez au combat, les missiles ennemis les ciblerons en premier. Puisque l'algorithme ne prend pas en considération ce genre de chose lors du choix des cibles, un missile Armageddon "gaspillera" 1005 points de dégats innutilement sur une frégate fragile et relativement sans potentiel offensif réel avant de renvoyer son attention sur les cibles que vous voulez vraiment détruire en premier. Veuillez prendre note que la rêgle du "une perte pour un missile" ne s'applique pas aux armes a rayonnement, les vaisseaux armés de lasers détruiront donc une grande flotte de leurre avec aisance. Veuillez vous référer à l'article de Art Lathrops pour une description plus détaillée des leurres et des nombreuses tactiques reliés a leurs utilisation. Alors que la plupart des joueurs considère l'utilisation des leurres comme étant une tactique ingénieuse et tout a fait légitime de l'application de la mécanique de jeu, quelque irréductibles considère toujours les leurres comme étant un bug équivalant a de la triche. Il est donc possible que vous rencontriez occasionellement une partie banissant son utilisation. Le joueur avertis prendra alors bien soins de demander à l'hôte la description exacte (incluant les plans de vaisseaux) de en quoi consiste un vaisseau "leurre" (et ce, bien avant que ce soit un problème), car la différence entre un leurre et un démineur peu onéreux peut être très mince.

Esquive de séparation de flotte (Split Fleet Dodge)

• (sensiblement) Rêglé au patch JRC4

Une flotte ne peut attaquer plusieurs vaisseaux que si ils sont tours regroupé au même endroit. Si vous divisez votre flotte en plusieurs petit groupes et que vous divergez leurs destination, une flotte ennemie ciblant la flotte en question ne pourra alors intercepter qu'une seule des flottes séparées (la flotte avec la masse la plus importante est le plus souvent celle qui sera interceptée). Une modification au code fut effectué à la version JRC3 pour éviter que plusieurs flottes pourchassant une même flotte ennemie qui se divise ne pourchassent toutes la même et unique cible.

Recyclage UR/CE (UR/CE Scrapping)

Une race avec le trait secondaire CE n'a besoin que de la moitié du prix listé pour bâtir des moteurs, tandis que une race avec le trait secondaire UR est capable de recouvrir jusqu'a 90% des ressources et 70% des minéraux utilisés dans la création des vaisseaux récupérés. La mécanique du jeu ne prend cependant pas en considération le fait que la race CE n'utilise que la moitié des ressources et des minéraux pour la construction de moteurs lorsque ceux-ci sont récupéré à une base appartenant à une autre race, se fiant donc au plein prix. Un vaisseau qui n'est qu'un moteur glorifié (comme un scout avec un moteur très cher) peut être utilisé entre deux joueurs d'une même alliance pour générer des ressources et des minéraux "gratuits". Ce bug est partiellement contré maintenant que les vaisseaux transférés à une autre race (incluant les vaisseaux reçu par les MT) sont automatiquement considéré 30% moin cher lorsque le calcul du recyclage est lancé.

Surcharge de la grille de combat (Battle Board Overload)

La grille de combat ne peut utiliser qu'un maximum de 256 pièces en même temps (divisé équitablement avec tout les joueurs présent dans le même combat). Les pièces en trop sont tout simplement laissés de côté pour le combat. Les pièces retenus sont basé sur le numéro des flottes, les numéros les plus bas ayant priorité. Chaque joueur est garantie un nombre minimal de pièces pour le combat équivalant à (256 / nombre de joueurs présent), les pièces non utilisés divisé équitablement de nouveau pour les joueurs entrant le combat avec une flotte supérieur au minimum calculé, jusqu'au maximum total de 256. Il est possible de prendre avantage de cette limitation en divisant sa flotte en deux, la première flotte consistant de 256 leurres ou de vaisseaux sacrifiable et la deuxième flotte consistant de vaisseaux destinés a ne pas prendre part à la bataille, et en redivisant la première flotte de nouveau en 256 flottes d'un seul vaisseau. Cette technique vous permettrait alors d'éviter la bataille pour le cout de 256 vaisseaux facilement sacrifiable ou, sur une échelle réduite, de faire en sorte que des vaisseaux critiques et vulnérables ne participent pas à la bataille (ex: bombardiers et cargos). La majorité des joueurs considère l'utilisation délibérée de cette technique comme étant de la triche a moin d'avoir été spécifié comme permis par l'hôte avant le début de la partie.

Dégats minimum de 0.2% (0.2% Minimum Damage)

La mécanique du jeu calcule les dégats au points d'armure pour une pièce donné au cinq cent douzième près (1/512, ou 0.2%). N'importe quel coup en combat (qui réduit les points d'armure) sont arrondis au prochain 1/512ème du total des points d'armure de la pièce. Ceci n'est pas un problème en temps normal, mais peut être abusé. En construisant 100+ DD ou Nubians armés de torpilles Alpha ou Beta et en les divisants en flottes d'un vaisseau chacun juste avant le combat, les vaisseaux lanceront un nombre de salves extrèmement élevé (100 flottes de un seul Nubian avec 9 points d'ancrage chacun et équippé de torpilles Beta = 900 salves). En groupe ces vaisseaux ne causerait normalement qu'un total de dégat insignifiant, mais puisqu'ils sont seul ils feront tous un minimum de 0.2% dégat par salve. Et avec 900 salves a 0.2% chaqun le total sera donc de 180%, assé pour totalement détruire une pièce (quel que soit le total des points d'armure de la pièce) et endommager de 80% une seconde pièce, à chaque tour. Avoir plus d'une torpille dans le même ancrage n'améliorera pas les dégats, mais avoir deux ou trois torpilles dans le même ancrage améliorera votre chance de frapper par ancrage (les missiles qui manquent leurs cible de causent pas de dégats aux points d'armure). Veuillez prendre note que les boucliers ne sont pas calculé de cette façon. La rêgle du "une perte par missile" s'applique toujours même avec le 0.2%, ce qui veut dire qu'un dernier missile est nécessaire afin de détruire chaque vaisseaux d'une pièce qui atteint 99% pour la destruction finale. La meilleur chose a faire pour contrer cette tactique est de séparer dans un premier temps votre propre flotte afin de minimniser la perte de vaisseaux et, dans un deuxième temps, lancer dans la bataille des vaisseaux équipés de Gatling (car les Gatlings frappent chaque pièces à portée de tir).

Pointage Public Caché (False Public Player Scores)

La mécanique du jeu calcule les ressources réelles au milieu du processus de génération de tour, mais calcule les ressources du pointage public a la toute fin du tour. Il est possible d'abuser de ceci en chargant des colons de toute vos planète avec un ordre de Waypoint 1 (après les déplacements) pour ensuite les décharger avec un ordre de Waypoint 0 (avant les déplacements). Ceci n'affecte en rien la production en tant que tel mais réduit considérablement le nombre de ressources sur lequel les points rapportés dans le pointage public sont largement basés. Ceci pourrait faire en sorte que d'autres joueurs ne réalisent pas assé vite que vous êtes en train de vous sauver avec la partie (et donc de faire front commun contre vous) avant qu'il ne soit trop tard. Il est a noter que cette technique pourrait bien se retourner contre le joueur si il est prit en flagrant délit, car les autres joueurs sauront alors que vous avez quelque chose a cacher et donc pourrait décider de faire front commun pour vous arrêter (ce qui est exactement ce que vous voulez éviter en premier lieu).

Immunité aux mines Nord/Sud (North/South Minefield Immunity)

• NON rêglé au patch JRC4

Ce bug inhabituel inhibe les calculs de probabilités de frapper un champ de mine lorsque une flotte se déplace au nord ou au sud absolu, en rapport è sa propre position de départ. Ce bug n'apparait pas si il y a le moindre mouvement vers la l'est ou l'ouest, ne serais-ce qu'une année lumière de différence. Ceci permet donc a un joueur de déplacer une flotte au travers d'un champ de mines en Warp 10 avec 0% de chance de frapper une mine. La majorité des joueurs considèrent l'utilisation délibéré de ce bug comme étant de la triche.[1]

Immunité aux mines de rallentissements East/Ouest (East/West Speed Bump Minefield Immunity)

• (Sensiblement) rêglé au patch JRC4

Similairement à la dernière entrée, ce bug affecte les mines de rallentissements lorsque une flotte se déplace vers l'est ou l'ouest absolue en rapport avec sa position de départ.

Enlèvement de colons des SS (SS Pop Steal)

• Rêglé au patch JRC4

Le radar Robber Baron peut voler des minéraux d'un autre joueur, mais normalement pas de colons. Lors de la patch J, le code de vérification pour empêcher le vol de colons par ordre Waypoint 1 (Transport|colonists|load all) fut désactivé. Ceci n'était pas voulu et il fut prouvé que ce bug débalançait le jeu lorsque utilisé. La grande majorité des joueurs considèrerait l'utilisation de ce bug comme une offense sérieuse à moin d'avoir été spécifiquement mentionné en début de partie.

Avertissement: Les transfers de minéraux effectués par ordre Waypoint doivent être fait à la main. Ils ne se produireront pas si les ordres standards sont utilisés car ces orders inclus tout aussi bien le transfer de colons.

Hack [freepop] ([freepop] Hack)

Il est possible, avec l'aide d'un programme externe et avec l'aide d'un éditeur de mémoire, de créer des colons supplémentaires, limité seulement par la capacité de cargos en orbite. Ce bug abuse une faiblesse du code lorsque des colons sont chargés a partir d'une planète non colonisé. Alors qu'il est normalement impossible de charger plus de colons que le nombre que vous avez déjà déchargé dans le même tour, un éditeur de mémoire peut être utilisé pour tromper l'interface à croire que vous avez précédemment déchargé des millions de colons, ce qui n'est pas vérifié par le programme hôte. L'utilisation de cette tricherie est habituellement considéré comme étant une offense tout a fait inexcusable.

Base spaciale au coût réduit (Cheap Starbase)

Si vous construisez une base spaciale VIDE sur une planète qui n'a pas déjà de base spaciale et que vous la construisez à 99%, vous pourriez toujours éditer le design tout en gardant les travaux complétés à 99%. Ceci voudrait dire que vous avez payé 99% du cout total selon le cout de la base spaciale vide, et seulement 1% du cout total du nouveau design.

Abus du code de chargement des minéraux (Mineral Upload)

L'interface du joueur permet le transfer de minéraux vers n'importe quelle flotte en orbite, même les flottes ennemies. Il est aussi possible d'envoyer des minéraux à une flotte ne possèdant pas d'espace de cargaison. Les minéraux ainsi transférés disaparaissent tout simplement. Certaine personnes ont abusé de ce fait pour faire disparaitre des minéraux d'une planète perdue en les envoyant soit a la flotte ennemie ou vers les bombardiers en orbites, privant les attaquants des resources minérales disponible sur la surface de la planète.

Surcharge de la liste des vaisseaux (Target List Overload)

Le maximum de flotte qu'il est possible d'afficher dans le menu contextuel apparaissant dans la fenêtre visuel de l'interface, lorsqu'un clique droit est effectué sur une flote, est de 100. Il devient donc impossible de sélectionner les flottes suppérieures aux cent premières lorsqu'un joueur possède plus de 100 flottes au même endroit (en orbite d'une planète, par exemple). Les flottes avec un chiffre de flotte inférieur sont affichés en premier. Il est possible d'utiliser la liste "Other fleets here" pour voir les flottes présentes, mais il sera alors impossible de les sélectionner.

Débordement des points d'armures du port spacial (Space Dock Armor slot Buffer Overflow)

Lorsqu'une race possède à la fois ISB et RS, bâtir un port spacial avec plus de 21 Superlatanium résulte en un erreur de calculation des points d'armures. Alors que le total de 21 Superlatanium installé sur un port spacial est de 16,000 points d'armure, 22 Superlatanium obtient un total de 49,518 points. Le maximum de 24 Superlatanium obtient 51,018 points d'armure. En comparaison, une étoile de la mort pour un AR avec RS plafonne à 31,500 points (en excluant les jouets des MT). {citation: Matt Laub} La race du joueur en question doit absolument avoir le trait racial secondaire RS et utiliser le port spacial pour que ce bug entre en effet. Pour plus de détail, voir ici au HWF.

--==--

ISB trumps IT gate scanning

Improved Starbases makes gates invisible to some IT gate scanning. ITs can't see ISB gates with 150kT/600ly gates and infinite/800ly. 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, either 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)

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.

• Thread at HWF

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.

• Thread at HWF

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.

Credit

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

See Also

• Discussion thread at HWF
• Standard Cheats Disclaimer