: 台港区所谓的阉割问题吵很久了
: 不过并只要想办合作活动就可以 日方跟台湾代理商谈版权
: 这又要跑一段流程
: PADW台港区本来就没有说要同步更新阿
: 更何况台港区负责发布活动消息的FB官方 根本还没放消息说台港区没PADW
: 预期到可能会爆炸的流量问题 先给日版的玩家玩 臭了吗?
: 韩版 美版假如都同步更新 独留台港区那没话说 可是现在没消息美韩两版同步吧?
只有我觉得先集中火力在推出自家版本更新后，再去搞其他版本比较“安全”吗？
这样的大改版根本是把一个入口放两个游戏，金币和石头还要能互通，
一发生BUG可不得了了，说不定会发生早期回溯惨剧(???)，
虽然港台版日版是同一个服务器上，但对口玩家不同，活动也不尽相同，
其实我是觉得还好啦...如果日版不幸发生大错误要维修个2~3天，
至少我们还可以切到港台版玩XD！(可以吗?
另一个不同步的猜想是，7月底要开PADW，但G社又希望今年底前推出“中文化”
在中文部搞中文化的时候加一个PADW，系统还没实际公开游玩过的那种，
感觉会增加相关负责人员不少负担吧？
我是这么猜想的，TvT

同一服务器，会日板运转出问题，台港板还能玩吗@@

我觉得台版没PADW可能还不是重点，重点是日版PADW延期有超丰富的补偿，台版却没有这点（换帐号先不提了

我是觉得的确该先专心做日本版本

台版服务器维修时 日版正常 很难想像是完全同服务器

另外日帐不能玩，台帐肯定也不能啊

蛤?台板没那些问卷活动喔?

在开之前 一切都是臆测 会不会打脸之后就知道了

加上前面就有不对等案例(活动送石),会让人觉得阉割正常

应该说 他对日服务器开了空头支票 补三蛋龙是没错从头到尾没有提到台版阿 台版没蛋龙很合理

时光机有参考价值 但是不一定准

日版服务器异常 只补偿日版 台版异常 也只补偿台版阿当初台版刚上GOOGLEPLAY出事时不就是这样

之前问卷地城复刻的时候 时光机也没讲最后一天会加倍

到底有没有台日版啊 前面有板友说只是分台日登入口

服务器相同 但是 客户端不同...

既然如此 又何必补偿"台湾登入口"呢?

像IOS跟安卓 就是不同客户端啊

问题1:感谢祭PADW第一次宣布延期送3石的时候日台版都有

想成不同服务器,但可以随时移民比较好XD

sh 当初的三石 是一天一天送 还是一次送

不过我没想到回朔问题,如果日版回朔,那台日互玩的帐号会??

像之前完CC干他码的IOS就爽领一堆石阿.安卓哭哭

再来 登入口肯定两个 服务器维修应该不太可能只关闭某方登入口 (以我之前架设RO服务器来看然后可以肯定的是 帐号数据库是同一个就是了所以服务器应该也是两个 (没有人维修服务器只维修登入

我个人认为是服务器不同,但都从相同的帐号库抽资料~

口的 而我记得有次维修台日版是错开的(? 希望没记错

所以日版中枪台湾的大概也中枪?

看你指的中枪是哪种...

所以如果日版回朔台版没回朔,不知道那个帐号变怎样

只有帐号SQL是相同 其他不同login 是登入口 account 应该用chr 也就是帐号人物map 就是游戏内部资料 BOX 等级 等等 然后这些数据

台泥大师也是资讯相关科系的?

存在SQL里面 前三个有台 日版 两组 SQL则是一组共用没 我本身是商科的 但我自己架设过 RO＿服

反正我不管是什么中枪拉 就是中枪啊 跟我说台日版会不会有不同就是惹

现在台版这个状态一脸就是被暗示永远不会有PADW的样子

中枪的部分不同会导致不同的结果阿

服务器坏掉不会有事 但当哪天关卡出事导致绝金大量洗就有可能会让整个数据库重置时 就会

RO server的架构不一定和PAD相同吧，相隔那么多年，游戏类

型也不同。PAD的帐号资料很精简，肥在道具栏(box)，而且account map的资料SQL也有一份，感觉就只是index减轻SQL

其实SQL都大同小异~但PAD台日版这样搞,其实对帐号满危险的~

再精简的数据都是靠SQL那些数据库在处理的

负担的意味。小型app的登入动作不会这么复杂(离题)

台泥你讲那个是用MySQL+客户端模拟架的方法吧 原场应该是

我同意很危险 尤其是两个服务器不同时运行

Aegis 不是用MySQL这种架构

触控BUG那么久GH在装死就很干

RO本身的特性就很妙 史上第一个只要送封包 不用装游戏就能BOT的线上游戏

Aegis 我没有接触过 差异会很大吗@@?因为我跑过石器 RO 天堂 虽然内部东西不同但目前架设的东西大同小异

Aegis那套印象中是原厂开发专用的 当时流出版本到工会战

最古老的时候 用txt记录帐号资料 要修改会看到眼花XD

Aegis 是一本蓝色的那个书吗?

txt那个我也经历过 XD

蓝色书是我国中的时候的东西 +255还会当机勒= =

用sql来直接称呼数据库看起来说不出的怪...这是语法的名称，而且不是所有数据库都用sql=ω=

哦@_@a 这个描述和athena+SQL模拟的架构一样耶 A_A

只能+10 哭哭 反正呢 如果游戏公司要帐号回溯依照现在的技术 不会整体回溯 而是采取个别的 别担心因为我最常用的就是Mysql 所以直接用SQL叫 抱歉XD

虽然好像很专业 不过后面好像挺离题了XD

因为数据库三个字看不习惯....啊 应该用DB

习惯叫SQL+1XD,学过MSSQL及MYSQL,回溯问题在于,我在日版打

我看到登入要四个流程直觉就觉得有冗余动作，又或者account

到A,之后又去台版打到B,但因为A有问题需要回朔,台版的B消失

map其实也是DB或DB mirror，又或者account和map为何不合并?

哦 因为我是用RO的角度来讲 后来想想 好像会少一两个

帐号登入login-> 角色读取char->进入游戏读取map

再说login本身只是auth的动作，后续要怎么取资料是另一回事

噢 这样的话，应该 map(item) ⊆ account(chr) ⊆ 帐号好吧，就到这边好了 XD