: 台港區所謂的閹割問題吵很久了
: 不過並只要想辦合作活動就可以 日方跟台灣代理商談版權
: 這又要跑一段流程
: 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