画面左下にある、「スマホ用入力欄表示」で、日本語(その他言語)を入力できます。
ログイン画面で使うと、名前に日本語を使う事もできます。
#moveマジックで、スマホ用の移動パネルが表示されます。
ぽちぽち押して移動してください。
(押しっぱなしができる端末では、連続で移動できます)
iPadでは、Puffinというアプリを使うと、普通にFlashが動きます。
http://itunes.apple.com/jp/app/puffin-web-browser/id406239138
250円です。
Puffinを使う場合は、マウスカーソルをうまく使うと、比較的ストレス無く、操作できます。
指二本でドラッグしたり、色々ためしてみてください。
たまに全く繋がらないことがありますが、Puffinのタスクをキルすると、つながります。
アンドロイドはFlash搭載のブラウザなら、問題なく動きます。
(日本語入力は上記のやり方です)
音声・動画の受信は、問題なさそうです。
配信が出来ないのは調査してないので、今後の課題です。
(出来るかどうかはわかりません)
●ログのURLクリックを実装
●受信許可、あぼん関連の不具合を修正
●ﾙｰﾗ/ﾘｽﾄで配信者名を表示
●お知らせメッセージでパネルがクリックできない不具合を修正
●鰻道改造
●#tweetで現在位置のログインURLをつぶやけるようにした(ルーラ不可エリアは使用不可)
●swfをFlash8からFlash9にバージョンアップ
●ID表示機能を拡張(GM用)
●噴出しテキストにビットマップキャッシュ適用(描画速度向上のため)
●ジュニアの配信箇所復帰
●神社をルーラ可能にした
●ちんぽっぽを削除(まだその域に達していないため)
街頭TV(YouTube配信)は仕様上の問題で実装を見送りました。
座標ずれは、サーバーの処理が重くなってきているのが原因(？)と思われます。
近々、サーバー交換します。
……………突貫工事でしたので、そのうち直します…。
(追記)
「安定しないぞこら。」
→何回も再起動してすみません。
Flashの描画速度が速くなったみたいで、それに合わせて色々パラメーターを調整する必要がありました。
大分安定したはずですが、自信が無いので、神社でお祈りしてください。
(追記)
海岸の波がおかしいようです。
あちらを直せばこちらが…。
→修正しました
(追記)
ステージを1年も前に作ってくれてた、こふ先生ありがとうございます。
サウンドファイルご提供くださったかたもありがとうございます。
(追記)
MP増えすぎみたいですね。
→お賽銭すると、自分のMPは減って、周りの人のMPが増えるようにしました。
(追記)
名無し居酒屋の一期一会が消えてしまってるようです。
→修正しました。
(追記)
お賽銭が、現実世界で請求されることはありません。
(追記)
ログインできない人がいるのは原因がわかりません。
バージョンアップの兼ね合いでアンチハックの仕組みが誤動作してるかもしれません。
→設定をミスしてました。修正したので大丈夫だと思います。
(追記)
>ちんぽっぽの服装って神社実装にちなんでですか？
ちなんでですね。
開発の人が作ってくれてた神社シリーズに含まれていたので調整して実装しました。
やっぱり神社には巫女ですよね。
(追記)
>KWSサーバーのバグ
上記設定ミスが原因でしたので、修正済みです。
度々アク禁ログが出てたのでデバッグが助かりました。感謝。
ひさびさの前向きな更新です。
ここのところ問題が連続していて
なかなか時間がとれなかったのですが、
お盆で連休が取れたので更新をかけました。
追加した機能は主に２つ。
1つ目は、RSSの自動収集機能。
教室にネタニュースが表示されるようになってますが、
これはRSSの自動収集機能を使ってます。
他にも、天気、地震、YouTube/ニコニコのランキングあたりは
RSSで収集できそうです。
需要があれば、随時、実装していこうかなと思ってます。
2つ目は、BIND機能。
これは素材とサーバーデータをBIND(連結)する機能です。
たけのこで使ってます。
こういったユーザー全員でデータ(たこのこの座標etc)を共有する機能は
これまで管理人の私しか実装できなかったのですが、
v114から開発陣でも作ることが出来るようになりました。
ちなみに、たけのこのコードはこんな感じです。
-----------------------------------------------------------
// BIND変数名(定数)
var C_BIND_VAR_NAME = "takenoko";
// ギコポイオブジェクト取得
var GikopoiObject = _level0.GetGikopoiObject();
// 初期設定
var TakenokoY = -25.8;
DoBind( TakenokoY );
// クリック時処理
TakenokoBody_mc.onPress = function()
{
TakenokoY -= 1;
if( TakenokoY < -187.8 )
{
TakenokoY = -25.8;
}
GikopoiObject.SetBindVariable( C_BIND_VAR_NAME, TakenokoY );
}
// BIND時処理
function OnBind( ipBindVarName, ipBindValue )
{
if( ipBindVarName == C_BIND_VAR_NAME )
{
DoBind( ipBindValue );
}
}
function DoBind( ipBindValue )
{
TakenokoY = parseFloat( ipBindValue );
TakenokoBody_mc._y = TakenokoY;
}
-----------------------------------------------------------
"takenoko"というのがサーバーの変数名で、
今回は、たけのこの表示位置を格納してます。
onPressで、たけのこの座標を減らしてサーバーに再格納。
OnBindで、変数が変わったときの処理(たけのこの位置をずらす)を実装。
こんな感じです。
なお、GikopoiObjectというのが今回のミソで、
このオブジェクトによって、
素材からぽい本体の機能にアクセス可能になってます。
いまのところ、
SetBindVariable() ... サーバー変数の設定
GetPlayerName() ... ユーザー名の取得
GetPlayerId() ... ユーザーIDの取得
くらいしか公開してませんが、
このオブジェクトの機能を拡張すれば、
かなり凝った素材が作成できるんじゃないかと思ってます。
(たとえばオセロとか。ぽいにゲームが必要かという議論は別ですが。)
教室のニュースもOnBindで処理してます。
黒板の素材で、サーバーで更新しているニュースのデータを読み込んでるわけです。
今回、他にも高台とか、黄泉とかを作ろうと思ってたんですが、
時間が足りなかったため先送りにしました。
ステージの作成は、一番時間がかかる作業なんですが、
ここのところ、開発以外で時間を取られていたため、
なかなか作業が進んでません。
副管理人のような職をつくって、
ある程度、処理をまかせるのが良いのかなぁとか考えてます。
でも、権限を委譲すると、副管理人にも管理責任が発生するわけで、
そこらへん難しいところですよね。
とりあえず今回の更新内容は以上です。
※ 開発中の高台。もうちょっと調整が必要ですねー。
>>ストリーミングの話はすごく面白いです。今日び個人でも
>>イーモバなんかで簡単に生中継の映像配信できちゃうわけで
>>法律が技術に追い付いてないって感じですね
仕方のないことなんですが、前線にいる立場としてはツラいですね。
法律(というか法の解釈というのか)のあいまいさで
被害を被るのもバカらしいので、
この際オープンに議論して防衛策を考えておきたい、
というのが今回の趣旨です。
>>音楽配信もまともに取り締まれてないのに
>>動画までやったら防止している・・・とはいえないんじゃないだろうかね。
良い意見だと思います。今議論してるのはまさにその点です。
名無しさんは、
「音楽配信もまともに取り締まれてないのに 」とおっしゃってますが、
果たして取り締まる義務があるのか？というのが今議論してるテーマです。
>>悪質なものを流してる人を取り締まるにはそれなりのチェックが必要なわけですが
>>そこまで運営さん達ができるかどうかじゃないでしょうか。
配信のチェック＝監視な訳ですが、プロバイダ責任制限法で、
プロバイダは監視義務を免除されています。
この手の話ではよく出る例ですが、
包丁を作った人が、包丁を使った殺人を監視する義務があるのか？
ってのと同じです。
(つづく)
>> とりあえず違法なデータを削除すれば
>> 何にせよプロパイダは罪に問われないって事ですか？
的確です。
ニコニコ動画も違法なデータを削除してるから罪に問われないわけです。
ぽいで問題なのは、削除すべきデータが無いことです。
前回の記事でお分かりいただけたと思いますが、
プロバイダの役割は、状態犯の後始末をすることです。
つまり、状態犯の犯人が生み出した、複製物を削除することです。
ところが、ぽいではモノが残らないので、権利侵害が継続しません。
じゃーぽいは何をすれば良いの？何もしなくて良いの？
それとも、犯罪を抑止する責任があるの？
って話になります。
んで、ここらへん、自信がないので悩んだんですが、
次回以降で、続けて考えて行きたいと思います。
(つづく)
ついてこれてる人がいるのか疑問に思いつつ、備忘録もかねて続けます。
ここで、そもそも論をします。
そもそも、ユーザーが著作権侵害行為を行ったときに、
プロバイダがそれを放置すると罪に問われるのは何故か。
当たり前ですが、犯罪の責任は、犯罪を犯した人が負うべきです。
が、ネットで著作権侵害行為が行われた場合、
直接犯罪を犯したユーザーだけでなく、
一見犯罪を犯していないように見えるプロバイダも罪に問われる可能性があります。
これは何故か？というのが今回のテーマです。
まず、この問題を考えるには、刑法を少しかじる必要があります。
刑法には、即成犯、状態犯、継続犯という概念があって、
それぞれ次のような意味を持ちます。
即成犯 ... 殺人のように、瞬間的に発生して、被害が一瞬にして終わる犯罪
状態犯 ... 窃盗のように、盗むという犯罪行為に続いて、
盗まれた状態(権利の侵害の継続)が発生する犯罪
継続犯 ... 監禁のように、犯罪が継続する犯罪
つまり、犯罪の状態を時間の経過と共に考えるわけです。
これを踏まえた上で、ネットでの著作権侵害行為を時間の経過と共に見てみると…
(A)ユーザーによる違法コピー(犯罪行為)の実行
(B)違法コピーがサーバー上に残って配信され続ける(権利の侵害の継続)
という状態の遷移が起こっています。
これは刑法で言うところの状態犯に相当します。
この場合、(A)と(B)の責任は誰にあるでしょうか？
答えは違法アップロードを行ったユーザーにあります。
このユーザーは違法行為によって罰せられるべきで、かつ、
権利侵害の継続による損害を賠償すべきです。
ところが、突然、このユーザーが交通事故で死んだと仮定します。
(A)は犯人の死亡と共に消えます。(B)はどうなるでしょうか。
死ななくても行方不明になったり、連絡不能になったとします。
そうすると(B)は削除されないまま、サーバー上で権利の侵害を
継続し続けることになります。
では、この権利の侵害を止める責任は誰にあるのか。
プロバイダです。
プロバイダが(B)の違法コピーを削除しない限り、
権利の侵害が延々と続いてしまうことになるため、
プロバイダは、違法コピーのデータを削除する義務があるわけです。
(これはどちらかというと社会的な義務だと思います)
もっと悪質なケースも考えられます。
例えば、掲示板に違法アップされたエロ画像が
アクセス数を稼げるからといって、
違法なのを知って放置したような場合、
プロバイダは罪に問われてしかるべきです。
以上が、いわゆる「放置」をしたときに
プロバイダが罪に問われる可能性がある事の根拠です。
なお、この話は、プロバイダが違法行為を知っていた場合に
限り成立します。知らないところで起こっている権利の侵害を
プロバイダは止めることが出来ません。
ところで、この解釈(上記解釈は一般的な法的解釈だと思います)は、
ストリーミングが考慮されていないように見えます。
ストリーミングの場合、継続的な権利の侵害が発生することが
ないため、瞬間的な犯罪のように思われます。
(つづく)
次に、前の記事であげた項目について、
詳しく説明していきたいと思います。
まず(1)についてですが、この項目は、正確には、
プロバイダは違法行為に対して一定の措置を講じていれば、
通信の内容に対して責任を負う必要が無い、という内容です。
一定の措置というのは、つまり(2)と(3)です。
なんだ当たり前じゃないかと感じるかもしれませんが、
プロバイダ責任制限法が出来る前は、
いくら違法行為を防止しようとがんばっていても
プロバイダが罪に問われる可能性がありました。
日本ではそのような事は起きていないようですが、
アメリカでは1993年にプレイボーイ事件という事件で、
掲示板の管理者が罪に問われています。
プレイボーイ事件とは、
画像掲示板にプレイボーイの写真が貼られ、
著作権者であるプレイボーイ社が、
写真を貼ったユーザーではなく、掲示板の管理人に対して訴訟を起こし、
結果、管理人に罪があると認定された事件のことです。
このとき、管理人に過失があったかどうかは一切考慮されず、
ただ、プレイボーイの写真が貼られた掲示板の管理人であったというだけで
侵害行為者だと認められてしまいました。
これを無過失責任(過失が無いのに責任がある状態)と言いますが、
プロバイダ責任制限法は、このような理不尽な責任が発生するのを
防止するための法律なわけです。
このような事態を受けて、作成されたのが、
1998年にアメリカで制定されたDMCA(デジタルミレニアム著作権法)であり、
日本のプロバイダ責任制限法はそれを参考にして作成されています。
ちなみに、平成9年、日本でも同様に、プロバイダの責任を
問う事件がありましたが、その際は、ユーザー側に責任があるとの
判決が下りました(ニフティ事件)。
(つづく)
| 11 | 2024/12 | 01 |
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |