Home » Stars! 2.6/7 » The Academy » Known Bugs (JRC3)
| Known Bugs (JRC3) |
Fri, 21 February 2003 19:27  |
|
|
|
Known Bugs in Stars JRC3
Original document copied directly from Stars! FAQ
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
...
[Updated on: Wed, 11 May 2005 15:47] by Moderator
Report message to a moderator
|
|
|
|
| Re: Known Bugs (JRC3) |
Sun, 23 February 2003 07:27  |
|
 Robert |
 | Lt. Junior Grade |
Messages: 393
Registered: November 2002
Location: Dortmund, Germany | |
|
2 more bugs:
mineral vanishing:
if your planet is bombed by enemy ships, upload minerals to
their fleet (which has no frighters!), next turn the minerals
are gone...
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...
i think the first one is really hard to detect, and can be
painful in the late game, when you fight for minerals...
the cheap starbase trick seems to be really evil when you first
know about it, but there is a simple solution: allow it!
(and tell everybody how it works...)
this is not as hard as it seems, as it just changes the way to play the game... in the late game it is not that important anyway, cause bases dont add much defense anyway... ITs may get
and advantage, as they can build a gate quickly, but still you
need 2 turns, and if an it wants a gate up in 2 turns, he can
do it anyway... this is also countered by the fact that anybody
can build cheap MDs quickly, which is a disadvantage for IT, as
they are weak with massdrivers... so i think its fair again.
so - later in the game bases are unimportant anyway, and in the
early game the situation is quite different. once you got a plaent, it is difficutl to take it away from you early. so it
is much more efficient to grap as many planets as possible, and
build a full equiped fort there soon...
just changes the playing style, as usually it is more efficient
to colonize the _fat_ greens first to optimize growth, but so
it is better to get all greens early to get controle...
well... i played in 2 games, where this cheat was explained
to everybody first and then allowed - no problems had....
but mineral vanishing is nasty...
just what i think... open for discussion 
robert
2b v !2b -> ?Report message to a moderator
|
|
|
| | | |
| Re: Known Bugs (JRC3) |
Tue, 15 April 2003 00:33 |
|
|
|
my bad i was going to the site that showed the patches as being
Patch for 2.70H:
st27h27i.exe -- 417,420 bytes
Patch for 2.70G:
st27g27i.exe -- 418,328 bytes
Patch for 2.70F:
st27f27i.exe -- 418,359 bytes
Patch for 2.70C:
st27c27i.exe -- 419,530 bytes
Patch for 2.70B:
st27b27i.exe -- 419,529 bytes
Patch for 2.70:
st27027i.exe -- 422,945 bytes
and didnt see anything about a path saying 2.70j hince the problem i was having.
thanks for the info though, found that patch.
Report message to a moderator
|
|
|
| | |
| Re: Known Bugs (JRC3) |
Tue, 15 April 2003 17:00 |
|
| Micha | 
 | |
Messages: 2342
Registered: November 2002
Location: Belgium GMT +1 | |
|
| Quote: |
what i do is to set the name of the race at beginning of
race design and not change it anymore after that...
sounds strange, but it _is_ a possible reason.
|
Not that strange since it comes forth from even more protection against hacking ...
| Quote: |
also if you use netscape to submit the files, that might
be a problem. i know netscape sometimes messes up .x files,
maybe also racefiles?
|
Yup, race files too IIRC, has to do something with the settings in Netscape, you can fix it, but can't remember exactly how ... something to do with MIME and adding the .x# and .r# as file type ... ??
Or you can just zip the race file (or .x-file), with that file type Netscape doesn't have a problem ...
| Quote: |
hm.... but i think it does not necessarily mean you use the wrong patch...
|
Seems in his case it was ...
regards,
mch
Report message to a moderator
|
|
|
|
| Re: Known Bugs (JRC3) |
Wed, 16 April 2003 11:17 |
|
| regiss |
 | Petty Officer 1st Class |
Messages: 65
Registered: November 2002 | |
|
| Quote: |
something with the settings in Netscape
|
Files smaller than 1Kb are treated as ASCII files by default in
Netscape. Simply register .x# .r# file types as binary.
Report message to a moderator
|
|
|
| |
| Re: Renaming Races |
Wed, 16 April 2003 21:59 |
|
| BlueTurbit |
 | Lt. Commander
RIP
BlueTurbit died Oct. 20, 2011 |
Messages: 835
Registered: October 2002
Location: Heart of Texas | |
|
If you leave the race name blank the program will use "Humanoid" as the race name.
If you leave the plural name blank the program will use the race name for the plural name.
The other races will see the plural name id on your planets, and they will see your ships as the race name in the summary, except when they point to the emblem under the ship, then they will see the plural name instead of the race name.
So if your race is named 111 and the plural name is 222 then:
Other players will see you as the 222s on the public score sheet. They will see your planets as belonging to the 222. And when they click on one of your ships the summary will say it is a 111 ship. But when they click on the emblem under the picture it will say it belongs to the 222 race?
So if you play SS you could name your race the "not", and the plural name the "there".
Then when the other players discover your HW and ships they will say to their allies:
"There HW is there, but their ships are not there"
And the other will say "where are there ships"
And the first replies "I don't know, there ships could be anywhere, but I know they're not there. Why? Is there a problem with there?" 
In conclusion, there is no conclusion. This all depends on what happens in the JRC5 patch. 
[Updated on: Wed, 16 April 2003 22:07]
BlueTurbit Country/RockReport message to a moderator
|
|
|
| | | |
| Re: Known Bugs (JRC3) |
Fri, 30 May 2003 11:04 |
|
|
|
It was most likely an overflow error. Either it expanded past the edge of the galaxy or exceed the size of the memeory location alotted to store the minefield information.
"There is no substitute for Integrity"Report message to a moderator
|
|
|
|
| Re: Known Bugs (JRC3) |
Fri, 30 May 2003 20:51 |
|
|
|
I've done that too.
Worst, though, is when I made an IS OWW race. It started doing that overflow, and a lot more. Eventually, it reached the year 3138 and when I try to generate, Stars! comes up with 'floating-point error: overflow' and crashes. Here's a picture:
http://www.users.bigpond.net.au/djhakase/stars!-crash.gif
The question is, which overflow crashed it?
Was it the excessive pop? The excessive space pop growth (3.6 million a year)? The excessive fuel on the that fleet? The excessive number of ships in that fleet? You'll notice the mines for that planet is '1' - that's a result of overflow as well.
In fact there's probably 3 or 4 other overflows going on in the background too. Maybe someone should make a list of overflows and at what point they occur?
they made me do itReport message to a moderator
|
|
|
| |
| Re: Known Bugs (JRC3) |
Mon, 02 June 2003 10:38 |
|
|
|
| Hatterson wrote on Sat, 31 May 2003 15:18 |
I doubt that this will actually affect anyone in a real game, but I thought that it was an interesting bug.
|
Actually, this might be causing another problem I've seen. In large games with an SD about, the game files occassionally go south. What I mean is you start seeing strange messages and the occassional error, then about 6 turns later, you can't even gen anymore. The whole game is a loss. I've been in two games where this has happened and heard about a few more.
I think I'll forward this to Jeff McBride and see what he says.
Jeff
Report message to a moderator
|
|
|
| |
| Re: 2 new Bugs to discuss |
Sat, 25 October 2003 20:06 |
|
| EDog |
| Lt. Junior Grade |
Messages: 417
Registered: November 2002
Location: Denver, Colorado, USA | |
|
| Robert wrote on Sat, 25 October 2003 06:02 |
- if you are at the same position as your enemy and want to chase him, then he might set a waypoing without having enough fuel to reach it. The chaser "overshoots" and ends up at a point where the fleet had gone without running out of fuel.
So it is impossible to chase...
- you can send 2 mineral packets from one planet the same turn, by building a packet, updating the base design, and sending another packet of a different kind of minerals. ends up having 2 packets at the same location...
open for comments, cheat or trick?
robert
|
Well, the first one is a trick, but to little benefit of the chasee. Essentially he will be stuck with no fuel (or drop to W4) and the chaser can turn around and overtake him the next turn and punish him mightily for having the cojones to try and pull a fast one.  
The second one is clearly a bug along the lines of the free starbases bug. If you are going to disallow that one (and any sane host would), this one should be disallowed as well. Where is becomes difficult to catch someone exploiting the free starbases, this one will be very obvious (I'm assuming that a target world would get two "A mass packet has been detected..." messages). Either way, it's naughty. 
Thanks for bringing these up, Robert!
EDog
http://ianthealy.com
Born, grew up, became an adventurer
Report message to a moderator
|
|
|
|
| Re: 2 new Bugs to discuss |
Sun, 26 October 2003 04:08 |
|
|
|
The first one IS open to abuse:
Just include a fuel transport in the fleet, so you generate some new fuel every turn - this way you never get stuck at warp 4 and can continue to 'run out of fuel' attempting to travel at warp 9 on EVERY turn...
Definately a 'cheat/abuse' if it can be used like this. (I haven't tested)
Report message to a moderator
|
|
|
|
| Re: 2 new Bugs to discuss |
Sun, 26 October 2003 08:29 |
|
| Robert |
| Lt. Junior Grade |
Messages: 393
Registered: November 2002
Location: Dortmund, Germany | |
|
Yes, I see this is important to discuss...
Especially as I think exactly the opposide! 
To compare the multi-minral-packet trick with the cheap starbase trick is not really correct. With the cheap starbase trick you get something without paying for it, with the multi mineral trick you have to pay for the second base, and as you have to change the massdriver types/numbers, and massdrivers cost a lot, it is quite expensive.
So you get nothing for free, and realistically, if you build a completely new driver, why not also a new packet?
As for the cheap starbase trick:
yes it is a bug, and yes you get something for free. The problem is that you cant control it well. So i put a lot of thinking into consequences when this would be allowed. What happens? Some say IT gains an advantage. Maybe... Gates are cheaper for IT, now everybody can build gates for free. Also now everybody can build massdrivers for free, more disadvantage for IT.
So, I dont think IT has much of an advantage.
What happens is, that it changes the way the game is played.
People will tend to grab space and planets much more quickly,
and once they got a planet it will be theirs for a while...
It is just different, usually you distribute pop to have efficient growth, now you would distribute pop to grab planets quickly...
The only PRT with real disadvantate is the AR. AR cant use the trick.
So... in normal games where you cant check I am usually very paranoid... I watch neighbours very carefully, checking designs and estimated resources if he did not cheat... makes me not feel much better... so... i am not sure...
I guess either you allow it, or you need a neutral third party to check, and really check here and there. If someone is caught, kick him out... If you got no neutral third party, well...
In the end: what is victory worth, if you know you achieved it by cheatint? But not everybody thinks like this...
Ok: to the fuel bug...
I think this is cheating!
You have no chance to chase someone, and this can be abused to destroy minerals once your planet has been attacked. load mins into freighers move them away using the trick, and next turn scrap, or delete the design... ok - stupid example... SD can lay
minefields this way and cant be caught... there are more examples i guess... harmful ones...
and if you like to test, you can calculate the coordinates you will arrive and send another fuel transport... whatever...
IMO this is a cheat...
so... still open for discussion i guess (in the end each host has to decide on his own, and players have to follow).
Robert
2b v !2b -> ?Report message to a moderator
|
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 22:04:22 EDT 2024
|
Members
Search
Help
Register
Login
Home
Re: Known Bugs (JRC3) ADDITION
