クラフトレシピ･･･

･･･おきつねさまの開放済み一覧を纏めて診る試行。



☆ 緊急の殆どに参加していないので、inさえしていれば クラフト依頼には 比較的即応し易くなってます。


<<< 20180705 041135 >>>
イル・グランツ 閃光 Lv.3 開放


<<< 20170922 145512 >>>
上級法撃武器(★7～9) Lv.9～12まで開放、残るは Lv.13のみ。
【更新】クラフトレシピ 開放分 追記。


<<< 20160318 055007 >>>
サ･フォイエ 効率 Lv.3
シフタ 数多 Lv.3
ナ･フォイエ 火焔 Lv.3
イル･フォイエ 効率 Lv.3 


<<< 20160131 033129 >>>
上級射撃武器 Lv.7/8 デイリー分で開放。


<<< 20160131 033129 >>>
PAクラフト Lv.25 デイリー分で開放。


<<< 20160131 032556 >>>
PAクラフト Lv.24 デイリー分で開放。


<<< 20160130 040035 >>>
中級射撃武器 Lv.11/12 デイリー分で開放。


<<< 20160128 083021 >>>
初級法撃武器 Lv.14/15/16 デイリー分で開放。


<<< 20160124 133747 >>>
イル･フォイエ 効率 Lv.2 ／ 集中 Lv.1 デイリー分で開放。


<<< 20151209 213757 >>>
イル･ザン 広域/集中 Lv.2 デイリー分で開放。


<<< 20151209 213757 >>>
武装エクステンド Lv.37 デイリー分で開放。


<<< 20151208 003158 >>>
PAクラフト Lv.21 デイリー分で開放。


<<< 20151201 214325 >>>
PAクラフト Lv.20 デイリー分で開放。


<<< 20151201 003848 >>>
PAクラフト Lv.19 デイリー分で開放。


<<< 20151118 070137 >>>
PAクラフト Lv.17 デイリー分で開放。


<<< 20151107 214720 >>>
サ･メギド 集中 Lv.2 デイリー分で開放。


<<< 20151030 070216 >>>
PAクラフト Lv.14 デイリー分で開放。


<<< 20151021 224613 >>>
ザンバース 効率 Lv.2 デイリー分で開放。


<<< 20151001 191849 >>>
サ･フォイエ 火焔 Lv.2 デイリー分で開放。



<<< 20150922 133613 >>>
ナ･グランツ 閃光 Lv.2 デイリー分で開放。



lt;<< 20150811 093000 >>>
ラ･ザン 風斬 Lv.1～3 開放(されたw)


<<< 20150808 124500 >>>
デバンドとレスタのレシピ3出しをする。
しかし シフタ道半ばでリリパリウム枯渇、ナニ? レシピ3を50回って苦行は･･･(´ﾍ｀；)



<<< 20150808 094900 >>>
CreateLog･･･
　
　

ここな きつねが･･･

･･･PSO2の現状で忌諱している対象は、過去から一貫して、その推移が要因の状況だ。

はっきり云って内容云々は興味が無い、ツマるトコ、システム面だけが その対象だ。

具体的には、

★ アーキテクチャが未だ WindowsXP世代であるにも関わらず、最新鋭のハイエンドスペックマシンを要求する傾向が強まっている点。

ロースぺ切り捨てなら、64bitビルドで DirectX12に対応した版を配布しろ。

また、実質ハイエンドありきな現状 DirectX9cもナイだろ?

64bitビルド版も並行配布して然るべきな状況を、もはや運営自身が作り上げているのだが?

何より、

今となってはローエンドな機材でさえ 64bitプロセッサと64bitWindows搭載だ、今更 32bitビルドも無いだろ?

クライアントが64bitになると、サーバ側が 32bitで合わなくなる等と云い出さないよな?

ココで断言しておくが、縦しんば サーバ側が 32bitアプリケーションのまま、
クライアントだけ64bitビルドしたからと云って、通信にも稼働にも支障は出ない。

クライアントを 64bitビルドとして仕立てても、
ソースを大幅改変しない限り、サーバと通信されるデータの内容に違いは生じない。

TVtest(64bit) と TVチューナサーバ Spinel(32bit) の関係が良い証拠だ。

PSO2なんぞより 遥かに大きなデータ通信量のある、
ネットワークに対して高負荷なアプリケーション同士でも成立している。


そんな素人騙しな言い訳は一切認めない。




★ UI の構成が Windows の仕様に合致しない点。　
キャンセル操作1つ取っても それを満足に満たせていない。


★ 未だに、ウィルス認定受けた nProtect Gameguard を使い続け、 
　　Microsoftから同類扱いされている点。
アンチチートセキュアシステムくらい 自前で組め#

★ 海外からの接続を公式には認めていない点。

WANを用いたネットワークサービスで何が恥ずかしいって コレよな。

厄介抱えたくないだけなら、接続自体を自己責任と明示した上で、海外からの接続に対して正式に開放するべき。
その上で、ローカライズも言語対応もしないスタンスでイイ。

仮に、多言語対応したいのであれば、現地ボランティア募れば解決だ、現状と何処が違う?
違いが無いのなら、労せず国際的評価を上げる手段としてコレを実施するコトが良策であるのは、明確だ。


これらは流石に看過出来ない、様々な要素で 国際的に恥を曝しているに等しく、これでeSports参入など、もはや戯言にしか聞こえない。

ぶっちゃけゲームのバランスなど、プレイスキルの無いおきつねさまには そもそも関係が無い。

顧客に対する最低限あるべきシステム面の配慮が欠落している事に、憤慨し続けてきた。
もはや その変化の発生の有無くらいしか、PSO2には興味を持てる点が無い。

Highpoint Rocket640L を･･･

･･･ASRock 990FX Extreme4 [Windows10 Pro RS2] に載せると、

Windows10起動開始直後に 100%フリーズする･･･

コレが GIGABYTE GA-MA78GM-S2H(rev.1.0) [WindowsVISTA SP2 32bit] では、支障なく動作する。

挿す板が ASUS U3S6 であれば、何れのマザーボードでも、トラブル無く機能すると云う･･･
　この差異の検証に丸一日浪費した(´ﾍ｀；)

一旦状況を整理すると。


Marvell MV9230(88SE9230) を PCIeバスへ直接接続する構造が Highpoint Rocket640L。


PLX Technology(現Broadcom)製 PCIeブリッジチップを介して、SATAⅢチップ Marvell 88SE9123 と
USB3.0チップ NEC(現RENESAS) uPD720200 を PCIeバスへ繋ぐのが、ASUS U3S6。


Marvell 88SE91xx系と 88SE92xx系は、ドライバが同じ。


ASRock 990FX Extreme4 は 2port分だけ、追加のSATAⅢチップとして Marvell 88SE9120 を採用している。


GIGABYTE GA-MA78GM-S2H は、Marvell製含む補助的なSATAⅢチップを搭載していない。


USB3.0側に関しては、問題が生じていないので今回の件では扱わない。


他の可能性を虱潰しに検証し、要因から排除した後、最終的に

990FX Extreme4 の オンボードの補助SATAⅢチップ Marvell 88SE9120 を UEFIで無効にして診たのだが･･･

これで漸く990FX Extreme4上でも、Rocket640L の動作検証が出来る状態となった。


要するに、

2つのマザーボードの、Marvell製SATAⅢチップを搭載して要るか否か と云う違いが、差を生んでいたコトに。

ASRock 990FX Extreme4 では、

サブHBA Marvell 88SE9120 と Highpoint Rocket640L の Marvell 88SE9230 が、
Windows開始と同時にコリジョンを起こし、起動処理継続が困難になった･･･
　これが 今回のトラブルの原因だったと云う、掛けた時間の割りにはシケた結果に。


だが･･･

起動前に Highpoint Rocket640L へドライブを繋ぎ通電しておくと、やはり Windows10は起動出来ない。
UEFIでオンボードの88SE9120を無効とする事で、部品としての動作検証が出来る状態にはなったが、実用性は皆無。

MSU(MarvellSettingUtility)で 88SE9230のRAID機能を完全に無効化すれば、
或いは機能するのかも知れないが、そこまで検証するのはやめた。

88SE9120 は 接続端子数 2port の RAID 0/1/5 に対し、
88SE9230 が 接続端子数 4port で RAID 0/1/10 である点など、
基本的な仕様が異なっている事が、起動の妨げになっている要因
(マザーボードのUEFIが処理しきれてない?)であると仮定すると、
どの様な検証も無意味 と云うコトになってしまうと考えた。


無難にシステムを運用する為にも、マザーボード側に Marvell製SATAⅢチップが搭載されている場合、
Highpoint Rocket640L は使用不能 と判断するべきだろう。

ただ、

このような障害が発生しない製品もあるとの報告もあるようで、マザーボードの仕立て次第と云う事だろうか･･･

ヤフオクの･･･

･･･出品利用を忌諱していた理由がココにある。


女子中学生チケット詐欺の複雑怪奇な手口を
Githubのシーケンス図でわかりやすく説明する猛者が出現 - Gigagine [ 20170913 102800 ]

一度ヤフオクで落札して診れば判る事だが、落札者側には、出品側の個人情報が表示される･･･

否、その内容を確認していなければ、後に発生したトラブルには対応しない と警告が表示される。

冷静に考えると、逆なんじゃないかな、コレ･･･

取引を開始する為に、ヤフオクのシステムに促されるまま出品側情報見て、

相手が女性と判った時の 微妙な気まずさと云うか･･･

一応添えるなら、これに関して性別偏見や他意は無く、落札商品もPCパーツくらいしかないのだが、
折角のネットワークシステムであり、可能なら 相手を知る事無く 正しく取引さえ行えれば、本来ソレで、
適宜完結出来るハナシでは無いだろうか? と、強く感じた次第。

サービス提供側が適宜全取引ログを保存していさえすれば、犯罪発生時の捜査対応も容易である。


Amazonのマーケットプレイス等ショップサイトならイザ知らず、オークションで相手を知る必要性が見えない。

むしろ個人情報詐取系犯罪の温床となっている空気すら感じる。(Amazonですら その問題は生じている)

納得の価格で、適切な商品が届けば、正直相手が誰でも構わないと考える。

不正な出品者は、被害落札者からの情報や、捜査機関からの情報を基にオークションシステム側で検出し、
適宜弾いておけば良いだけであり、現状でも充分 その様な仕組みが稼働している筈だ。


ぶっちゃけ、
オークションに出会いなんぞ求めてない。
　この一言に尽きるだろう。


★ この件に関する解決策は、

ソフトバンク系列 メルアド宅配便 の 不効率で不便な欠点を排除した仕組みを ヤフオク側で標準処理として実装するだけで良い。
もう少し資本規模を活かした太刀廻りが出来ないモノかな? ヤフオク運営諸兄。
頭を使うのです、ちゃんと食べてるのですか?