惟漫

某次服务器维修前10分钟连爆20双+8战靴
以后再也没敢在维修前冲装备

pandawin

很多库例程产生的“随机”数是准备用于仿真、游戏等等；它们在被用于密钥生成一类的安全函数时是不够随机的。其问题在于这些库例程使用的算法的未来值可以被攻击者轻易地推导出来（虽然看起来它们可能是随机的）。对于安全函数，需要的随机值应该是基于量子效应之类的确实无法预测的值。

Linux 内核（1.3.30以上）包括了一个随机数发生器，对于很多安全目的是足够的。该随机数发生器收集来自设备驱动程序和其它来源的环境噪音放入一个熵池。在作为/dev/random被访问时，只返回熵池中预计的噪音比特数之内的随机字节（如果熵池为空，则调用被阻塞，直到收集了附加的环境噪音）。在作为 /dev/urandom被访问时，即使熵池为空也返回所要求的那么多字节。如果用随机值作加密用途（如产生一个密钥），则应使用 /dev/random。更多的信息可以在系统文档random(4)中找到。

芊芊

原帖由 OTL 于 2006-10-11 13:11 发表
概率,是在收集大量客观事实数据后所作的统计结果,而LZ很明显在只把概率当作是计算机里面的程序操作,无法交流

虽然我不同意楼主的看法，但是你的看法也不同意
实质上程序中的概率确实跟现实的概率有着本质的不同
实际上的概率是不可控制的，但是程序中的概率发生率却是人为控制的

虽然程序员都会学过概率学，但是却没人会吃饱了撑着把程序中概率的计算设定得过于复杂（过于复杂的结果有两个，其一是对硬件要求急剧提高，其二就是在进行程序debug的时候需要的时间更长）

看客的意思大概就是我的意思了。但是具体是如何操作的我也不知道。大方向就是设定了一个几率表而已。在程序运转的过程中提取这个表的值来做true和false的判定而已

程序中每个事件都依存这个表进行判定，但是这个表不可能极大。否则会大量的占用内存导致系统性能下降（指服务器）。CRO运行快4年了，这个表应该轮回了无数次。但是从未有提及50连暴的事件发生。故此推断此事件的发生概率为0。实际计算中这个事件的发生概率为7e-27，实际上计算也可以认定为0

Mr.CooL

有啥好辩的 人品无敌才是王道

ro_ll

计算机中最普遍最容易的做法是取余数：

x = 取当前系统时间 % n(n = 预设概率，比如:100、500、1000...)
if(x == 0)
  成功
else
  失败

所以，如果真的是采用这种方法，理论上讲完全相同的精炼状况在相同间隔时间产生完全相同的结果(即使是这样简单。很遗憾，你别忘了那是指服务器时间，由于网络传输信息的时间无法做到非常精准。所以你不用妄想用你的计算机和服务器时间做个同步，除非你在服务器上插了个时间控制木马)

-------------------------------------------------------------------------------

为了防止连续出现成功(或失败)次数太多，可能会有成功(失败)记录，这就是为何有些人乐忠于频繁上下线和在成功精炼之后连续冲暴几个无关紧要的物品，那可不是受到FLG影响:
如果你连续多次成功(失败)多次，意味着你的成功(失败)率在下降，要靠下线清除纪录(不下线维持纪录)来争取最大成功率。

凤凰倾城

其实很简单,就是成功和失败.

程序里那和现实中不同的概率,也会遵循现实里的概率.

简单的比喻下,就是随机产生1个数(1-10),跟精炼值比较大小判定成功还是失败.我想官方的概率是针对产生的随机数而言的,至于玩家成功还是失败,看RP的.

havtousmaj

在程序中实现现实的概率是完全可能的。不要怀疑计算机的每秒上亿次的计算能力。通常会有相当好的库函数以供调用，用过MATLAB的人肯定知道这一点。即使不是这样，那编写一个概率函数也并不困难，可以实现的比现实的概率还概率
所以lz我不同意程序中的概率和现实的有区别这个说法。

不过像千千所说的完美会导致负担加重会有可能的。但是我们不能判断RO程序编写是否真的遵循了现实的概率。而概率的统计必须在大数的基础之上。小数应该是靠所谓的RP咯，体现不了和概率的一致。。150双包148的这位同志其概率可以和偶尔买一张彩票中一亿美金的阿婆相比了，但绝非完全不可能哦。

[ 本帖最后由 havtousmaj 于 2006-12-17 15:26 编辑 ]

qwenlww

谁挖的坟……