|
| Re: Mineral upload / download (Re: Known Bugs (JRC3)) |
Mon, 09 August 2004 16:29   |
|
| Kotk | 
 | Commander |
Messages: 1227
Registered: May 2003 | |
|
It is known display problem that for non-RS races opponent RS shields are somehow displayed buggily. Think yourself:
When there are 3 such RS FF-s and 1 such cruiser fighting each other from range 3 then the cruiser should never get frigates shields down.
Cruiser does only 94 dp damage and frigates regen 84 dp per round. Effective damage per round from cruiser is therefore 10 dp until shields are up. Since frigates have 840 shields it takes like 80 rounds to kill these frigates for that cruiser. Since frigates have more firepower that cruiser is long dead before that. Battle has only 16 rounds btw... how they got to 34?
[Updated on: Mon, 09 August 2004 16:35] Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: Mineral upload / download (Re: Known Bugs (JRC3)) |
Mon, 04 October 2004 20:54 |
|
|
|
I would like to clarify that an AR using a non-AR coloniser to build initial oribital fort is NOT a bug.
Speak now or forever hold your peace if my HE works with an AR to minicolonise orbital fort everywhere!
Report message to a moderator
|
|
|
|
| Re: Mineral upload / download (Re: Known Bugs (JRC3)) |
Tue, 05 October 2004 05:16 |
|
|
|
heh, no I don't think thats a bug. An HE could trade miniclonizers with any race, altho I agree that AR would get a bigger deal out of it than most. Out of curiousity, is the 1000 colonist payload low enough to avoid travel pop losses?
Report message to a moderator
|
|
|
|
| Re: Mineral upload / download (Re: Known Bugs (JRC3)) |
Tue, 05 October 2004 07:07 |
|
| Kotk |
| Commander |
Messages: 1227
Registered: May 2003 | |
|
| gible wrote on Tue, 05 October 2004 12:16 |
Out of curiousity, is the 1000 colonist payload low enough to avoid travel pop losses?
|
2200 do never lose any on road. This is not bug too i hope?
[edit: made typo its 2200 not 2100]
[Updated on: Tue, 05 October 2004 08:49] Report message to a moderator
|
|
|
|
| Re: Mineral upload / download (Re: Known Bugs (JRC3)) |
Tue, 05 October 2004 07:22 |
|
|
|
Technically it probably is being as it arises from the limitations of the engine, namely the fact that 2% of 2100 gets rounded(to the nearest 100) to 0 but I'm not about to go thru the effort of making up an addition to the original post and sending it to Ron so he can edit the original for something so minor...maybe once I have more to add...
...if I remember. 
nah...I probably would remember...every so often I re read most of this thread looking for enough new stuff to make it worth editing the original...a very small service, but its my post and I like it to be up to date.
Edit: To answer your fear: tis not cheating IMO(and I would mark it so)..and I did a quick back-read...very little editing to be done...cheating vs split fleet...NS minefield still buggy...nothing extremely significant.
[Updated on: Tue, 05 October 2004 07:37] Report message to a moderator
|
|
|
|
|
|
|
|
|
| "New" Bug (Re: Known Bugs (JRC3)) |
Thu, 03 February 2005 23:34 |
|
 mlaub |
 | Lieutenant |
Messages: 744
Registered: November 2003
Location: MN, USA | |
|
Hi
I was somewhat surprised that a Space Dock of mine lasted 2 battle rounds against Armaggedon Nubs, and decided to take a closer look. After reviewing the design and playing around a bit, I concluded that this is either a "new" bug, or it is further evidence of my terrible math skills ... 
Bug - Space Dock Armor slot buffer Overflow?
Result - More armor than a Death Star...
Requirements - SuperLat, ISB, and RS
If your race has ISB and RS, building a Spacedock 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). I do not get the same results with a non-RS race. The Space Dock seems to be the only unit effected, as I did a quick check through other ship hulls and SB's. I presume that the 24 slot is to blame.
I have never heard of this bug before now. Frankly, I would be surprised if I am the first to notice this bug. However, I checked through the list, and did not see it. Perhaps someone could verify this? if it checks out, it should be added to the bug list.
-Matt
Global Warming - A climatic change eagerly awaited by most Minnesotans.
Report message to a moderator
|
|
|
|
|
| Re: "New" Bug (Re: Known Bugs (JRC3)) |
Fri, 04 February 2005 09:58 |
|
| Downsider |
 | Crewman 1st Class |
Messages: 35
Registered: June 2003
Location: Derbyshire, England | |
|
This bug is a strange one. It seems that Stars! treats the armour value for a slot as a signed integer when compensating for RS when the armour value is treated as unsigned by the rest of the game.
At some stage before it halves the armour, the RS algorithm comes up against a limit of 32000 or 32768 and returns 0 if the value is greater. It then reduces the armour by half of what it should have been, giving a negative number. It stores this as the normal binary code for the value but with the last (16th) bit as a 1, denoting the number negative.
This is interpreted by the rest of the engine as being a positive integer made up of half the normal armour value plus 2^15 (32768)
In the case of 24 superlat the numbers go like this
24 * 1500 = 36000 = 0 (greater than 32000 or 32768)
0 - (24 * 1500 / 2) = -18000 (signed) or 50768 (unsigned: 18000 + 32768)
adding 250 for the armour of the base gives 51018 which is the armour value given by stars.
Things to note:
1. This can only happen on a stardock because it's the only hull capable of holding 24 armour parts in a single slot.
2. I'm not sure if this is an error caused by the generic stars limit of 32000 or a programming limit, which would be 32768.
"Violence is the last resort of the incompetent" - Salvor Hardin Report message to a moderator
|
|
|
|
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
(or am I just terrible at math 
)
Auto-build items do not block the queue. If they cannot be performed, they are skipped over.