Fix fighter bays not launching due to VCR Random Number List
Please implement the possible fix described in detail by Joshua in the third post on this page:
http://planets.nu/discussion/fighters-not-launching-after-first-wave
partial quote: "we could simply add another 1000 values or whatever to the 119 to make this all much more smooth and prevent this kind of weird thing. So we could certainly "fix" it."
Given the rather common adverse affect this has on low-bay carriers, I would like to see this change implemented.
We have released the new Expanded Combat RNG to address this
-
Whisperer commented
Additional threads where this issue is discussed:
http://planets.nu/#/activity/3233039
http://planets.nu/#/activity/3261898 -
emork commented
I'd really like to see this randomness reduced. Be unlucky two times and your well and long prepared planed fizzles.
A bit randomness is fine like
* launch speed of a carrier can vary by e.g. 10%
* beam charge can vary by e.g. 10%Losing ships because no bay launched or no beam fired doesn't fit to a strategy game like this. You spend much time for economy and logistics to build and position your fleet and it's very demotivating if you're defeated not by your enemy but by the random number generator.
-
indigo ferrinor commented
I voted for this, but I don't see the problem in the fighter bays.
I'd like to see those random number lists fixed in general. -
Whisperer commented
> there is a long active thread discussing this right now and a lot of agreement that it is a legitimate bug that should be fixed.
That thread is http://planets.nu/#/activity/2686860
-
Anonymous commented
Here's a couple solutions even... Rather than mucking with the RNG tables for the purists that don't want the probabilities messed with, try this out. As others have speculated, it is almost certainly connected to the 7 * 17 = 119 issue (pit an SSD vs an SSD or a Super Star Carrier vs a Gorbie/biocide/100 def planet with starbase, all these scenarios calculate out to 34 (which is divisible by 17) events per tick and have problems). The number of events you can expect in a combat tick before torps or beams are in combat range = (total number of beams) * 2 + (number of ships with fighter bays). It is 2x for beams because there is a 'fire at fighters' stage and a 'recharge beams' stage, regardless of whether any fighters are around to get shot or if any beams need recharging. The other is a check for each ship with launch capabilities to see whether it'll launch anything that tick.
Probably the most straight forward fix guaranteed to work is to actually do the above math. If that number comes out to a number divisible by 7 or 17, then you know you could get stuck in this loop so just advance the seed by 1 so that it can't. Code looks like this, drop it at either the top or bottom (before the return statement) in the "PlayCycle: function ()" call:
var seed_ticks = 0;
if (this.Objects[0].BayCount > 0)
seed_ticks = seed_ticks + 1;if (this.Objects[1].BayCount > 0)
seed_ticks = seed_ticks + 1;seed_ticks = seed_ticks + (this.Objects[0].BeamCount * 2);
seed_ticks = seed_ticks + (this.Objects[1].BeamCount * 2);//check 17 first, then 7, because 34 (divisible by 17) + 1 = 35, which is divisible by 7 still
if (seed_ticks % 17 == 0) {
seed_ticks = seed_ticks + 1;
this.Seed = (this.Seed >= RANDOM_SIZE ? 1 : this.Seed + 1)
}if (seed_ticks % 7 == 0) {
seed_ticks = seed_ticks + 1;
this.Seed = (this.Seed >= RANDOM_SIZE ? 1 : this.Seed + 1)
}//You don't need to check divide by 17 again after this because the highest possible seed_ticks for a given round is 42 (10 beams and fighters on both sides) and this isn't a problem for the 7s until 7 * 12 = 84 (where 85 is divisible by 17)
****
Otherwise, the really really simplest alternative solution that would *probably* work is to change the line in RechargeBeams from :if (this.GetRandom100() > 50 && j < 100) {
to
if (j < 100 && this.GetRandom100() > 50 ) {
If javascript conditional evaluation works how I think it does (early termination), that should keep the RNG from advancing for any beams that are fully charged. It should disturb things just enough to keep the loop from happening, but no guarantees, there could still maybe be squirrelly corner cases. Would still be deterministic event ordering too; replayable, debuggable, etc. Safer yet if java doesn't do what I think, replace with this:
if (j < 100)
if (this.GetRandom100() > 50 ) {That'll also get the job done.
-
Whisperer commented
Here are a few of the many threads that have discussed the RNG issue in the past:
http://planets.nu/discussion/beams-not-firing
http://planets.nu/discussion/rightleft-combat-advantage
http://planets.nu/discussion/random-number-generator-sucks
http://planets.nu/discussion/hello-is-the-battle-simulator-for-ships-with-6-beams
http://planets.nu/discussion/oh-man-6500-fighters-destroyed-this-turn-that-was-fun
http://planets.nu/discussion/is-there-some-reason-ships-wont-fire-beams-sometimesI know there are more, as I've made posts about the RNG that aren't in any of the above, but it should be noted that the oldest of these posts is about 6 years old. This problem has been with us for quite a while.
-
Anonymous commented
Second this; there is a long active thread discussing this right now and a lot of agreement that it is a legitimate bug that should be fixed. It all started because as an EE player I lost most of my fleet because the leaders of the charge against a starbase, a pair of Super Star Carriers, completely locked up and instead of using 4 bays and 6 beams in combat both acted as though they had 0 bays and 5 beams. Game breaking.
I just feel really fortunate this happened in a tutorial game against the computer and not a real match that had been on going for 2-3 months. As a brand new player, if it had happened in a real game it would have been enough to make me quit playing forever.