一上午2次NOFIRE...20多万油没了不讲还耗我一上午时间...绝望..准备U号...

殖民星怎么样才算大呀，开的几个都很小

殖民星100以上足够，不过里面希望有4个比主星大，可以全面发展

2個15號 177  180
5個200+
主星只有2500電沒升了,準備爆掉做戰鬥星.

就我个人感觉，ORG U30的ACS问题，很有可能是程序多人战斗的处理没有进行优化，所谓的BUG，是数据处理异常。
说得详细点，就是：
OG的战斗，每艘船有两个变量和一个逻辑变量，即护盾与装甲与是否被攻击。战斗中，通过读取攻防双方的三围等级（在战斗中属于常量），进行盾和装甲的计算，被攻击过的，根据装甲的数值计算殉爆率与随机数进行对比，根据结果判断是否改变逻辑变量。
那么在ACS时，至少有三方参与战斗，那么攻防双方的三围等级就不能作为常量，必须作为变量，即每次选择好目标时必须检测目标所属阵营。错误可能就出现在这个环节上。
即使做好了三围变量的处理，可能在某个不被发现的环节上，存在着错误。而OG对战斗数据又有判断，对于出错的数据，就可能返回错误的结果。那么，当ACS方的数据被错误返回后，战斗就可能重新被“无误”的计算。
我猜想这是部分nofire或全部nofire的原因。

不懂,系統自己可以發現錯誤並重新計算?是這個意思嚜?
理解不了.

nofire

其实是什么意思？

服了






fire=开火，nofire＝没开火


就是两军对阵但没打就回去了

你这个推断可行。不过错误就出现在这个数据上，难以解释。
我觉得出错在时间计算上面。
比如原来无ACS，玩家A进攻玩家B，m时刻到达，于是服务器只要读取一下A舰队，B在m时刻状态，就可以进行攻击计算了。
但是ACS情况下，玩家A和C进攻玩家B。A在m时刻到达，C在n时刻打到。
若m<n,在A部队等待的这段时间内，服务器可能每过0.5秒刷新一下攻击方是否还有部队增加。因为若还有部队加入ACS攻击方，并且到B的时间为t，很可能t>n>m，这样，弄得服务器就要再度考虑t时候的数据，而且服务器还要考虑攻击方可能有部队召回。 服务器不断刷新双方的数据以确定抵达时间，于是造成了服务器接收数据过多，可能内部向量分配空间不够，导致溢出。
不好的情况就发生了，中间发送几次战斗，攻击方和防御方可能各有损失，甚至前面的攻击方被判定进攻完毕于是回家了。弄得n打1，变成了1打1。 如果是数据溢出，可能就是A B部队到达时间 m 和 n相差太大。