Home World Forum
Stars! AutoHost web forums

Jump to Stars! AutoHost


 
 
Home » Stars! 2.6/7 » The Academy » Known Bugs (JRC3)
Re: 2 new Bugs to discuss Wed, 29 October 2003 02:45 Go to previous messageGo to next message
Robert is currently offline Robert

 
Lt. Junior Grade

Messages: 393
Registered: November 2002
Location: Dortmund, Germany
Embarassed the multiple packet thing...


2b v !2b -> ?

Report message to a moderator

Re: 2 new Bugs to discuss Wed, 29 October 2003 02:58 Go to previous messageGo to next message
gible

 
Commander

Messages: 1343
Registered: November 2002
Location: Wellington, New Zealand

Indeed..the multiple packet thing...

Before I run off and write an addition to the bugs list(or god forbid.. some testbedding Laughing)

How little can you make the price(difference) of the new starbase?
Is it enuf to simply swap the driver and gate locations?
Do you *have* to change the driver type?

I vaguely remember trying it once by building an exact copy SB..and it not working.

Step by step please so both myself and Zoid can understand Very Happy

Report message to a moderator

Re: 2 new Bugs to discuss Wed, 29 October 2003 20:13 Go to previous messageGo to next message
Kotk

 
Commander

Messages: 1227
Registered: May 2003
gible wrote on Wed, 29 October 2003 09:58


How little can you make the price(difference) of the new starbase?



The difference must be big enough to achieve decay rate difference or situatin where the orbital cannot throw at set speed. The packets with same decay rate and speed merge.

Quote:


Is it enuf to simply swap the driver and gate locations?



No

Quote:


Do you *have* to change the driver type?



Not neccessarily. You may add another driver of same type and so the decay rate will change. You may use same mineral, does not matter.

Quote:


I vaguely remember trying it once by building an exact copy SB..and it not working.

Step by step please so both myself and Zoid can understand Very Happy


Arrow Decay rate example here ....
Initially you got station with 2 x MD 5 and set throwing speed to 8
your build queue:
iron packet
station with 1 x MD 5
bora packet
station with 1 x MD 6
germ packet

Now you get 2 packets in same location at warp 8, one with bora and other one with germ and iron, because 2 x MD 5 are equal to 1 x MD 6.

Arrow Another example with changing speeds ...
you got station with 1 x MD 6 and set throwing speed to 9
your build queue:
iron packet
station with 2 x MD 5
bora packet
station with 1 x MD 5
germ packet

Now you got 3 packets at different speeds (and locations), iron at warp 9, bora at warp 6 and germ at warp 5. Also ... your planet is still set to throw at warp 9 but since the driver now is warp 5 driver that cannot reach warp 9 it throws at warp 5.

Arrow Third example with same mineral ...
Initially you got station with MD 5 and set throwing speed to 8
your build queue:
bora packet
station with 1 x MD 6
bora packet
station with 1 x MD 7
bora packet
station with 1 x MD 8
bora packet

As result you get 4 bora packets flying at same location.

As far i understand it is not cheat or something... it is more like trowing tactical trick for PP. Packets thrown by different drivers must decay differently and so they must be separated. Wink But do not wonder seeing 12 packets coming from 3 nearby PP planets. PP is poor guy so there must be some fun playing it. Very Happy





[Updated on: Wed, 29 October 2003 20:15]

Report message to a moderator

Re: 2 new Bugs to discuss Tue, 02 December 2003 17:25 Go to previous messageGo to next message
vonKreedon is currently offline vonKreedon

 
Lieutenant

Messages: 610
Registered: March 2003
Location: Seattle, WA USA
My vote would be that the multi-packet trick is NOT a cheat, but rather a tactic. It is not something for nothing, but it is an excellent way to acheive multi-packet impacts on a target.

Report message to a moderator

Re: Known Bugs (JRC3) Mon, 23 February 2004 18:55 Go to previous messageGo to next message
Ptolemy is currently offline Ptolemy

 
Commander

Messages: 1008
Registered: September 2003
Location: Finland

I'd also agree that the multiple packet effect is not a cheat. Each packet is costing the amount of the mass driver reequired to build to throw it. For a PP this could be a decent way, (though somewhat costly), of getting that packet terraforming to work a little more effectively on nearby planets.

Ptolemy




Though we often ask how and why, we must also do to get the answers to the questions.

Report message to a moderator

Re: Fuel Bug Mon, 23 February 2004 20:33 Go to previous messageGo to next message
Ptolemy is currently offline Ptolemy

 
Commander

Messages: 1008
Registered: September 2003
Location: Finland

Evil or Very Mad
OK - I ran some tests on this 'fuel bug' and I wouldn't call this a cheat in all circúmstances though it can be exploited for cheating.

This ONLY works if the ship that is set to run out of fuel is at the same location as the ship that would want to chase it. In early game play it is quite common for a ship to intercept another and not completely destroy it then set the enemy ship as a waypoint for a chase. The chasing ship will indeed end up where the defender ship was supposed to be if it had enough fuel to get there. Logically, since we are travelling at warp speeds faster than the speed of light, as a chasing ship I tell my ship to go at the same warp speed as the ship I'm after - if he was able to deceive me (or he runs out of fuel) I would end up where I would expect him to be and he wouldn't be there - nifty trick.

However, this can be abused and most notably by an SD. If an SD sets a minelayer with NO fuel to travel somewhere at a warp speed that he doesn't have fuel enough to reach, his ship WON'T MOVE. The chaser will still go. The mines will of course get laid. Now the chaser will have to go through the minefield to go after the minelayer which will certainly move in the opposite direction. With a ship laying speed bump mines the chaser won't reach him for a while.

Granted, this is going to be an uncommon occurrance but, an SD could use a ship as a fuel transport and upload all fuel to it to keep a fleet in the same place. Incidently, a ramscoop ship with empty tanks not only doesn't move, but the tanks stay empty since Stars! not only considers the ship to have run out of fuel but also doesn't generate any from the ramscoop. A ship with not enough fuel will move as far as it can with the fuel it has.

Ptolemy






Though we often ask how and why, we must also do to get the answers to the questions.

Report message to a moderator

Re: Known Bugs (JRC3) Thu, 18 March 2004 15:46 Go to previous messageGo to next message
Steve is currently offline Steve

 
Officer Cadet 1st Year

Messages: 217
Registered: November 2002
Location: 40 deg N, 90 deg W
Robber Barron Pop-drop bug.

In a recent game as SS, I built rogues with a robber barron scanner and a variety of other stuff. Sneaky

I'd fill the rogues with colonists and wander around scanning the universe looking for places to set up housekeeping.

I had an opponent who colonized planets with small colonies so I tried to pop-drop the colonies. For some reason I could not invade the planet. I figured I kept screwing up the orders. Wall Bash Eventually I figured out that the fix for the Pop-stealing bug resulted that a ship with a robber barron scanner could not invade an enemies planets. This was quite annoying as all I had in the combat zone were the robber barron rogues.



No trees were harmed in the making of this sig. However, many electrons were terribly inconvenienced

Report message to a moderator

Re: Known Bugs (JRC3) Robber Baron pop-drop bug Thu, 18 March 2004 22:00 Go to previous messageGo to next message
Ptolemy is currently offline Ptolemy

 
Commander

Messages: 1008
Registered: September 2003
Location: Finland

This could be. Did you try using waypoint 0 orders on arrival for the next year?

I suspect that it will work BUT, being prohibited from using waypoint 1 drops because the ship has a robber baron is a handicap.

I'll run some tests and post the result.

Ptolemy


[Updated on: Fri, 19 March 2004 06:54]





Though we often ask how and why, we must also do to get the answers to the questions.

Report message to a moderator

Re: Known Bugs (JRC3) - Robber Baron pop-drop bug Fri, 19 March 2004 06:50 Go to previous messageGo to next message
Ptolemy is currently offline Ptolemy

 
Commander

Messages: 1008
Registered: September 2003
Location: Finland

I tested this and, yes, you can't waypoint 1 drop people if a Rober Baron is on the ship. Waypoint 0 drops do work. Therefore, this is a new bug and applies to any race using a Robber Baron ship with population in it. Most likely, Steve is correct that this is a side-effect of fixing the pop steal bug.

The only workaround is to use a second ship in the fleet without a Robber Baron to do the pop drop with as waypoint 1. The second ship will have to split off as a separate fleet for arrival at the planet.

Ptolemy


[Updated on: Fri, 19 March 2004 07:10]





Though we often ask how and why, we must also do to get the answers to the questions.

Report message to a moderator

Re: Known Bugs (JRC3) - Robber Baron pop-drop bug Fri, 19 March 2004 12:13 Go to previous messageGo to next message
Ron is currently offline Ron

 
Commander
Forum Administrator
Stars! AutoHost Administrator

Messages: 1231
Registered: October 2002
Location: Collegedale, TN
Ptolemy wrote on Fri, 19 March 2004 06:50

I tested this and, yes, you can't waypoint 1 drop people if a Rober Baron is on the ship. Waypoint 0 drops do work. Therefore, this is a new bug and applies to any race using a Robber Baron ship with population in it. Most likely, Steve is correct that this is a side-effect of fixing the pop steal bug.
Ptolemy


Correct. It is a known bug (at least I knew about it), and if it isn't already in the main list, it should be.



Ron Miller
Stars! AutoHost

Report message to a moderator

Re: Fuel Bug Tue, 30 March 2004 18:50 Go to previous messageGo to next message
Dogthinkers is currently offline Dogthinkers

 
Commander

Messages: 1316
Registered: August 2003
Location: Hiding from Meklar
Ptolemy wrote on Tue, 24 February 2004 12:33

However, this can be abused and most notably by an SD. If an SD sets a minelayer with NO fuel to travel somewhere at a warp speed that he doesn't have fuel enough to reach, his ship WON'T MOVE. The chaser will still go. The mines will of course get laid. Now the chaser will have to go through the minefield to go after the minelayer which will certainly move in the opposite direction. With a ship laying speed bump mines the chaser won't reach him for a while.


IMHO This trick actually helps SD less than any other race - the SD ships drop mines regardless of whether they moved or not. This means it's a great trick for non-SD races wanting to both evade and drop mine, but the SD would drop mines even if it moved.

Obviously it has the potential to help SD a lot by the sheer quantity of tiny fleets the SD needs to evade with... This trick adds significantly to the MM needed to track these fleets down. Sad

Cool info BTW. Tricky to decide whether to view it as a 'exploit' or a 'feature' Confused

Report message to a moderator

Re: Fuel Bug Tue, 30 March 2004 18:56 Go to previous messageGo to next message
Dogthinkers is currently offline Dogthinkers

 
Commander

Messages: 1316
Registered: August 2003
Location: Hiding from Meklar
The 'fuel bug' effect also comes into action when a CE fleet fails to engage it's engines.

In my previous game I encountered this problem: My ally's fleet (at the same location) was assigned to follow mine into battle. My CE fleet failed to engage it's engines and remained in place that year, but unfortunately my Ally's fleet unwittingly flew on 'in pursuit', arrived at the enemy star and was promptly wiped out. Oops... All combined attacks were made at warp 6 after that... Laughing

Obviously the CE case is 'unexploitable' as a potential cheat as you have no choice over when it happens.

Just another drawback of CE I guess... Crying or Very Sad

** repaired some grammar Laughing **


[Updated on: Tue, 30 March 2004 19:14]

Report message to a moderator

Multiple mineral packets from 1 world in 1 year Wed, 16 June 2004 23:01 Go to previous messageGo to next message
Orca

 
Chief Warrant Officer 1

Messages: 148
Registered: June 2003
Location: Orbiting tower at the L5 ...
It appears that it's possible for one world to produce two or more mineral packets per year by the simple method of overloading the mineral limit of 32K/mineral type in the packet. For example, if you build a 32780kt ironium packet with a 26730kt boranium mineral packet following it.

This could be abused due to the defenses destroyed by the first packet. A PP could with a single planet wipe any non-PP planet; against another PP it'd still require two worlds however.

I doubt it will see much use (exempting late-game ARs and Wonka style games) due to the enormous mineral investment required, but it is something to keep in mind.



Jesus saves.
Allah forgives.
Cthulhu thinks you'd make a nice sandwich.

Report message to a moderator

Re: Multiple mineral packets from 1 world in 1 year Wed, 16 June 2004 23:38 Go to previous messageGo to next message
vonKreedon is currently offline vonKreedon

 
Lieutenant

Messages: 610
Registered: March 2003
Location: Seattle, WA USA
There is a more conventional way to produce two packets from one SB. IIRC, put a packet of one mineral in the queue, then a new SB (I can't remember if the driver must be different, I think that may be the case), then a packet of a different mineral.

Report message to a moderator

Re: Multiple mineral packets from 1 world in 1 year Sat, 19 June 2004 02:05 Go to previous messageGo to next message
Ptolemy is currently offline Ptolemy

 
Commander

Messages: 1008
Registered: September 2003
Location: Finland

There are numerous numerical limits in the game that can be overloaded. Stars! was created effectively in 16 bits using nothing more than long integers - hence the 32k limits. Many areas use only one byte variables and, arrays aren't unlimited. Most of this was done for 2 reasons; 1). Stars! was created way back in Windows 3.1 days - code execution speed was very important. 2). Back in Windows 3.1 days, people actually cared about the size of their code. The original Stars! releases were released on one diskette and that included all documentation.

If we think back to Windows 3.1, processor speeds were generally around 30 - 50 MHz. Machines ran 386 processors and, Stars! still ran fine. IMO, it is an excellent piece of programming for that era considering how much was created to fit into a very small package Razz

Ptolemy




Though we often ask how and why, we must also do to get the answers to the questions.

Report message to a moderator

Other tricks... Thu, 01 July 2004 13:23 Go to previous messageGo to next message
multilis is currently offline multilis

 
Lt. Commander

Messages: 789
Registered: October 2003
Location: Edmonton, Canada
I don't think these are cheats, it would be a nightmare to try and regulate and not much is gained. I think best to simply have a fair playing field where everyone knows what can be done.


Waypoint 1 at current planet:

If a ship waypoint 1 ends up at a planet, then waypoint 2 follows a ship (which also ends up at current planet)... Next turn waypoint 1 can be flipped to planet currently on.


Repairing moving ships:

Merging moving ships with stationary super fuel xport can lead to faster repairs

Report message to a moderator

Re: Other tricks... Fri, 02 July 2004 13:00 Go to previous messageGo to next message
Kotk

 
Commander

Messages: 1227
Registered: May 2003
I am wondering what is the usefullness of multiple waypoints at same location (other than maybe automating the pop drop trade without moving)?

multilis wrote on Thu, 01 July 2004 19:23


Merging moving ships with stationary super fuel xport can lead to faster repairs


It always leads to better repairs if battle does not occur at the destination.
Moving = gateing too (latter is very useful to instantly repair overgating damage).
Also it has not to be SFX there, it may be chaffie on orbit of dock (you get dock repair bonus there) and it may be fleet to what SFX is merged at same turn (still get SFX bonus).

Finally to AR guys out there. When gating the miners avoid mergeing them to anything at destination. AR miners remote mine after gating but not if they were merged to something same turn.

Report message to a moderator

Re: Other tricks... Fri, 02 July 2004 20:40 Go to previous messageGo to next message
multilis is currently offline multilis

 
Lt. Commander

Messages: 789
Registered: October 2003
Location: Edmonton, Canada
Quote:


I am wondering what is the usefullness of multiple waypoints at same location (other than maybe automating the pop drop trade without moving)?


There are a few situations where having the choice of waypoint 1 is useful due to order of events.

One example: You wish to capture a planet this turn, so you can build a gate the next... but you may wish to wait till AFTER the bombers do their work to reduce pop losses.

Report message to a moderator

Minefield bug Tue, 20 July 2004 09:58 Go to previous messageGo to next message
mitchell is currently offline mitchell

 
Chief Petty Officer

Messages: 71
Registered: November 2002
Location: Vancouver, BC, Canada
I would like to confirm that the NS (Std) and EW (Speed) movement through mines bug has been fixed in games running under AH.
Can anyone confirm?

Thanks in advance

K

Report message to a moderator

Re: Minefield bug Tue, 20 July 2004 11:27 Go to previous messageGo to next message
donjon is currently offline donjon

 
Lt. Commander

Messages: 808
Registered: November 2002
Location: Benque Viejo del Carmen, ...

JRC4 has fixed the bug Wink

Report message to a moderator

Re: Minefield bug Mon, 26 July 2004 16:58 Go to previous messageGo to next message
Micha

 

Messages: 2342
Registered: November 2002
Location: Belgium GMT +1
mitchell wrote on Tue, 20 July 2004 15:58

I would like to confirm that the NS (Std) and EW (Speed) movement through mines bug has been fixed in games running under AH.
Can anyone confirm?


I just ran a testbed:
- Fleets travelling EW or WE through a speed will be stopped.
- Fleets travelling NS or SN through a standard will not be stopped. However it seems that if you start inside a minefield you are not immune, those fleets will get stopped ...

So as far as I can tell the NS minefield immunity bug is not fixed if you start outside a minefield.

If anyone is interested, here is the setup. Set the fleets you want to test to warp10 and split them.
I used this version to gen, that's the version in the AH download section ...
If you get different results or if you find a mistake I made, please let me know.

Funny thing is that I can't seem to trigger the EW speed bug in jRC3 ... Confused Testbed won't work with older versions and not building a new one. Grin

mch


[Updated on: Wed, 27 July 2005 06:38]

Report message to a moderator

Re: Minefield bug Mon, 26 July 2004 21:22 Go to previous messageGo to next message
mlaub is currently offline mlaub

 
Lieutenant

Messages: 744
Registered: November 2003
Location: MN, USA
Micha wrote on Mon, 26 July 2004 15:58


I just ran a testbed:
- Fleets travelling EW or WE through a speed will be stopped.
- Fleets travelling NS or SN through a standard will not be stopped. However it seems that if you start inside a minefield you are not immune, those fleets will get stopped ...



IIRC, if the x axis movement is less than 10ly, chaff sweep calculators, and normal % chance to hit mines is thrown out the window. It's probably a lot less, as I tend to make rules-of-thumb that are clearly past the safty zone. Just in case... Wink

I learned this in a game situation, and never had time to go back and figure it out exactly.

-Matt



Global Warming - A climatic change eagerly awaited by most Minnesotans.

Report message to a moderator

Re: Minefield bug Tue, 27 July 2004 08:40 Go to previous messageGo to next message
LEit is currently offline LEit

 
Lt. Commander

Messages: 879
Registered: April 2003
Location: CT
For mine field calculations only, Stars! adjusts the speed a ship travels to the minimum needed to cover the distance.


- LEit

Report message to a moderator

Mineral upload / download (Re: Known Bugs (JRC3)) Thu, 05 August 2004 18:22 Go to previous messageGo to next message
Micha

 

Messages: 2342
Registered: November 2002
Location: Belgium GMT +1
Quote:

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.


I've been testing mineral upload/download ...

The idea is to find out what happens when uploading more minerals than the cargo space of the transports can hold. And what happens when you try to download/remove the minerals that you just uploaded (before turn generation).

Setting:
2 races. Race A uploads 300kT from the surface of a planet he controls to the transports in orbit belonging to race B. Those transports are 2 separate fleets of each one priv with a cargo hold of 250kT.

[- 01 -]
300kT upload by race A
=> next turn 50kT disappeared, they don't fall back to the surface

[- 02 -]
300kT upload by race A
save+submit
*close turn*
*open turn*

50kT download by race A
=> next turn 50 kT is back on the surface, 200kT in ship, 50kT disappeared

[- 03 -]
300kT upload
*not closing and opening turn*
50kT download
=> next turn 50 kT is back on the surface, 250kT in ship, no loss

[- 04 -]
300kT upload to fleet#1
race B merges fleet#2 with fleet#1 but target stays fleet#1
=> 300kT in fleet, no loss

[- 05 -]
300kT upload to fleet#1
other race merges fleet#1 with fleet#2 and target becomes fleet#2
=> all minerals back on the surface, 0kT in fleet, no loss




What happens when splitting fleets?

Setting:
Race A uploads 300kT to fleet#1 consisting of 2 privs with each 250kT cargo space (500kT total).

[- 06 -]
race B splits fleet#1 into fleet#1 and fleet#2
=> next turn fleet#1 has 250kT in cargo, fleet#2 is empty, 300kT missing on the surface, 50kT disappeared

[- 07 -]
race B splits fleet#1 into fleet#2 and fleet#3
=> next turn both fleets are empty, 300kT missing the surface, 300kT disappeared

mch


[Updated on: Thu, 05 August 2004 18:22]

Report message to a moderator

Re: Mineral upload / download (Re: Known Bugs (JRC3)) Sat, 07 August 2004 10:22 Go to previous messageGo to previous message
Kotk

 
Commander

Messages: 1227
Registered: May 2003
Micha wrote on Fri, 06 August 2004 00:22

I've been testing mineral upload/download ...


If you have some empty cargo space in each of your orbiting fleets you can easily see that your opponent is cheating. Wink If it was banned he has hard time to explain it. If it wasnot then wrong game for me.

The most hard to spot is cheap starbases cheat. One way to spot it is to have players passwords. Second effective is to have WM with top notch IS penscanners all over the place.

Report message to a moderator

Previous Topic: What's the best overcloaker design?
Next Topic: Mineral Packet Attacks
Goto Forum:
  


Current Time: Sat Apr 27 13:31:20 EDT 2024