オリジナルシナリオ製作時のトラブルシューティング
エラーを修正する際の経験・知識・対応策をカキコ。関数の不具合、使い方等製作テクニックに関連するものは各ページへ。
エラー原因の95％は、コピペ時や綴り間違い等のイージーミスに起因します。
※下記以外にも、避難所・改造スレをくまなく調べてください。
＜超初歩的なケース＞
- デフォシナ参考にいじりたいけど、なんか全部暗号みたいな文字の羅列なんすけど…どうやっていじるの？？
→ふりーむ版は暗号化されています。参考にしたいなら暗号化されていないwiki提供版で
＜スクリプト関連＞
エラーメッセージ
「スクリプトテキストに構文エラーがあります。
ファイル名：no file
行：0
ファイルがありません 」
→debug_paperの説明ページ参照
→用意するべきフォルダ名or置き場所が間違っている。『まずは君が作るVTオリシナのタイトル名のフォルダを作成して下さい。設置場所は一般的にオリシナを遊ぶ時と同じくvahrenのexeと同階層でいいでしょう。』（オリシナつくっちゃお！から抜粋）
原因：戦闘後のクラスチェンジ処理でループが生じている。
→各ユニットクラスのchangeがループしていないかチェック。
→他、イベント発生フラグの不整合が引き起こす場合も考えられます。
一番多いと思われるエラー要因
- 中括弧 { } の数、あってますか？
- 関数の綴り、使い方、引数の入れ方を間違ってませんか？（wiki参照＆熟読）
- 半角スペースが全角スペースになってませんか？(全角スペースで検索かける、とか）
- アルファベットが全角になってませんか？
- 変なところに改行が入ってませんか？
- 一連のイベントの行間にコメントアウトが入ってませんか？（中括弧内だと場所によってエラー出る？）
- クラス、ユニット構造体の name = ～ 内に半角括弧は×（半角スペースも？）
- 各構造体の名称がダブってない？きちんと承継できてる？
- 識別子（変数）は、
1.文字または下線 (_) を必ず含む。数字オンリーは×
2.下線 (_) で始まる文字列でもおｋ
3.スペースを含むことはできません。代わりに下線 (_) を使う
→半角スペースで挟んだ部分が表示されないみたい。ここでは半角括弧とかにも注意
※データを変更して、変更前の既存セーブデータから再開した場合、
- スキルの変更内容（挙動やエフェクト、弾数等）：適用される
- ユニットのステ、保有スキルの設定変更：生成済のユニットは変化なし、新しく生成されるユニットは変更が適用
- ユニットの識別子変更：旧名称で生成済のユニットが真っ黒表示になったりバグったり
- フェイス画像、アイコンの変更：適用される
- イベント関連のデータ：データセーブ時にその時点で存在するスクリプトデータが丸々保存されるぽい？ので、変更してもインゲームで適用されない。
- イベントのフラグ変更によって、ロード失敗やいきなりフリーズも起こり得ます。
→ユニット、クラス構造体のどこかに不具合あり。
例）goblin,fighterの固有クラスのキャラを作り、フレンドに一般クラスhuman,fighterだけを置く。本来の雇用はgoblin,fighter（一般未作成）であり、その分の欄に０が表示される。
＜アイコン＞
→ユニット記述部分のimage指定のつづりがまちがってる
→ユニット、クラス構造体のどこかに不具合あり。
＜ImageView関連＞
改造スレ参照。似たようなトラブル・質問が散見されます
- 最新版？にしてる？
- 古いVer？はJavaランタイム6ならとりあえず動くはず。Javaランタイムの最新は現在7-Update21
Java6なんて持ってない！→ググれ。（これ書いてる人は6-43使ってる）
※ただし、古いJavaは最新版に比べてセキュリティに脆弱性があるかも、自己責任で。これ書いてる人はセキュリティ関連疎いです。
古いやついれてると、自動更新のアラートうるさい→自動更新OFFに設定。
※追記（この記事を書いた人とは別人です）
ver.7.0_xx（いわゆるJAVA RE 7）ではアイコンの削除が作動しません。
Javaは基本的に後方互換性をそなえていますが、6→7以降に際して一部互換性がないということがOracle社のHPに報告されています。
アイコンの削除機能を使用する場合はJavaのヴァージョンに注意してください。
＜マップ＞
- マップチップがインゲームで表示されない！真っ黒！ または 前のまま！
→field.dat内の設定ミス、素材の名称と整合性取れてる？
stageフォルダ内のfield・objectフォルダ内データ、MapMakerのデータ、field.dat、Imageviewで表示するマップチップを固めたimagedataで１セット
→変更前のセーブデータ使ってない？
＜BGM＞
→拡張子が間違っている（wiki参照＆熟読）
→デバッグペーパーでmusicoffがそのままになっている
→MIDI音源の場合、設定してある曲数が多いとおかしくなるみたい。曲数減らすか、データ容量かさむけどMP3に変換等すれば回避可能。
複数の作曲家のmidiを使っていると曲毎の設定が違うため起きやすい。プレイヤーの場合は再起動。
＜素材使用に関連するあれこれ＞
これ書いてる人は著作権関係に特別明るくないです。が利用者として最低限守るべき・考慮すべきと考える点
（実際のトラブル解消法ではありませんが、トラブルを未然に防ぐ意味でこちらに記載とします）
- ほとんどが善意且つフリーで素材提供して頂いているもののはず。まずは提供者には最大限の謝辞と惜しみない感謝の心を。
- Readme等へのクレジット不要なものもありますが、これはひとつの礼儀として記載するべき。
- ＜重 要＞ 提供者の意向を「正確に汲み取る」こと。
（例）
「ご自由にお使いください」→「著作権放棄」「二次配布可」とは同意義ではありません。
「商用利用不可とは書いていない」→「商用利用可能」ではありません。自分勝手な想像・解釈で補完するな。
「ツクール製のゲーム専用素材です」→原則、流用はダメでしょう。
- どうしてもこの素材気に入った！流用ダメって書いてあるけど使いたい！or流用云々の可否は明記してない
→提供者に聞いてみるのはいかがだろうか。書いてないことなら要確認・相談・ネゴしてみる。ただし断られても恨まない。それでもダメなら自作しれ。
→Readme等で提供者が仰ってるのであれば改めて聞くまでも無くいいと思います。ただしクレジットに改変しました、の一文いれるのが親切と考えます。
ただし、言うまでも無いことですが公序良俗に違反したり常識を疑うような改変等はダメでしょう。（例：18禁に該当するような改変とか）
避難所スレでも何度か話題に上ってますが、まあこれも真似していいのか悪いのか、スッキリしなければ直接orスレ上にて真似したいスクリプト使ってる作者さんに聞いてみましょう。Readmeやスクリプトファイルのコメントアウト欄に流用・参考・真似っこOK！って書いてある作品もあります。
その上でReadmeや著作権表示欄のところで「○○様製作のスクリプト、参考にしましたーあざーす！」って書けば、スクリプト作者もそうそう悪い気はしないはず。
＜ちょっと特殊っぽい不具合＞
- セーブデータの一部(.sav)が破損して、該当データのロード・上書きセーブを試みてもフリーズ。それどころか手動で削除もできなくなった。
→おなじ番号の.savファイルをどっかで作って、それをペーストして上書き保存、で回避可能。
補足
※製作時のスクリプティング補助として、より機能的なテキストエディタの使用をおすすめします
＜メモ帳と比較した時の利点＞
・「元に戻す」の回数が多い、調整できる
・エラー時の該当箇所である行数の表示が分かりやすくできる（メモ帳でもできる）
・画面表示の詳細設定が可能（一行当りの折り返し文字数等）
・複雑な検索や置換機能がある
・メモ帳と違って保存ボタンを押さないでも仮保存してくれる機能があるものもある。
もちろんメモ帳でもワードパッドでもワードでも、使い慣れているものがあればそれでおｋ
- 半年前の記憶を元に書いたのでちょっと怪しいところも…おかしいところは修正・加筆おねがいします -- 名無しさん (2013-05-09 23:21:15)
- 素材関係についてはちょっと違和感ある。
「クレジット表記不要素材もクレジットを表記するのが礼儀」→飲み会の謎マナーみたいで草。確かに、ゲームはクレジット表記が容易な媒体で、例えばクレジット表記がズラッとある中で表記不要素材だけハブると製作者が誤解される等トラブルを避けるため表記した方が無難ではある。しかしそれをリスペクトやマナーの問題として広めるのは違うんじゃないかと。
「流用NGの素材を流用したかったら作者に聞いてみよう」→ツクール専用素材が流用不可になっている場合その理由のほとんどは権利問題。（ツクール同梱素材の改変とか、デフォキャラの二次創作顔グラなど）交渉してどうにかなるもんではない。聞くだけならタダで自由とはいえ、だいぶ無茶ぶり寄りの質問を推奨しちゃうのはどうかと思う。 -- 名無しさん (2023-10-08 16:14:58)
- とにかく素材利用は規約を「メモる」「読む」「守る」に尽きる。（どの素材がどこから貰ったもので、どういうライセンスになっているかわかるようにする素材管理も大事）
その上で「なんでもアリってどこまでなんでもなの？」「書いてないことだけどこれはやっていいの？」については「トラブルになることは避ける」が第一。
例えば、「なんでもアリって書いてあって商用規約がなかったけど禁止もされてないからオリシナ有料で売ったったわ」というケースがあったとして、法的には問題ないかもしれないけど素材製作者の善意に甘えている身でいざという時に製作者と闘争して権利を勝ち取る目論見を立てていたとしたら道義的に問題がある。「トラブルが起こった時に相手の不備を指摘して自分が正しいと証明する」ではなく「そもそもトラブルを起こさず互いに損をしない」を目指すスタイルの方がより製作者に対してリスペクトフル。 -- 名無しさん (2023-10-08 16:16:53)
- もっと言うと素材製作者も全員が善人かつ権利認識に隙が無いとも限らないので「怪しい素材は使わない」も選択肢の一つ。（5～10年前ならまだしも今時「なんでもアリ」とかゆるふわ規約の素材はヤバいかも、あと素材の規約は守ったからってニコニ・コモンズに営利利用可で転がってる野獣先輩のボイスなんか使ったらまずいってのはわかるよね） -- 名無しさん (2023-10-08 16:17:25)
- ヴァーレン特有で素材利用について気を付けた方がいいことは暗号化周りと実況・配信規約を設ける場合かと思う。
割合として多くないものの、素材の暗号化しないゲームへの同梱（音声や画像がそのままビューアやプレイヤーで開ける状態）を素材自体の再配布とみなして禁止している場合もあるので、素材を暗号化できたりできなかったりしたりしなかったりがあるヴァーレンでは特に注意。また、クリエイティブコモンズなど逆に暗号化する方を禁止している場合もありケースバイケース。結局のところ「規約をよく読む」が大事。 -- 名無しさん (2023-10-08 16:18:12)
- 実況・配信規約についてはヴァーレンだけでなくフリゲ制作界隈全体として素材規約をどう守ったら実況許可が出せるかが確かでないという問題がある。もっとも今時ゲーム用として素材を配布しつつ「うちの素材を使ったゲームは実況禁止！」という意図で素材規約を書いているケースは現実的ではない。基本的に素材は使って欲しくて配布されているものであり、トラブルになる可能性が現実的でないのであれば素材製作者の善意に甘えて緩めに規約を解釈するのもアリではある。
とはいえ、それは製作者に「ゲーマーの常識」が通じる場合の話。専用素材が少ないヴァーレンの場合、ゲームへの利用自体想定していない素材の流用も考えられるのでその場合は注意。
またクリエイティブコモンズについて、これは二次利用以降についてもしっかり決められた国際ライセンス。厳密に考えればゲーム実況も素材の二次、三次以降利用なのでCC-BYとかで守られている素材を使いつつ実況・配信規約を「実況歓迎！」の一言で済ませちゃったとしたらだいぶ問題がある。よく調べてライセンスを守った表記をすること。 -- 名無しさん (2023-10-08 16:18:35)
- ついでに超基本的な点としてヴァーレン本体の同梱素材は別にななあし氏が権利を持つランタイムパッケージではないので、オリシナに流用しての再配布は不可。説明書の上の方に素材抜き出し不可の一文があるし、勘違いしたとしても規約を確認する途中で気付くと思うけどたまにやる人もいるので注意。 -- 名無しさん (2023-10-08 16:18:45)
- 23番工房の素材とか再入手不可なんだっけ -- 名無しさん (2023-10-08 22:09:34)
- 最初のコメントが記載されたのが2013-05-09なので、2023年までに状況が変わって製作者に（なあなあで済ませるだらしない時代が終わり）より強い責任が求められるようになった？ -- 名無しさん (2023-10-08 22:12:52)
- 昔からたまご氏とかスマイル氏とか部屋隅氏とか苦労してらしたからなあ -- 名無しさん (2023-10-09 18:08:01)
- フリームにMOD登録が認められたりするけど、youtubeでは責任が求められる傾向にあるかも。しかし製作側としては開発初期から集客するということでなあなあ文化はまだ続いている。（迫真系統） -- 名無しさん (2023-10-09 21:54:14)
- わかってない人やわかった上でやらかす人向けに説明しようとすると長ったらしくなるけどぶっちゃけ基本は「規約を読め」の一言で済む。
最近はなんでもアリ系規約は減って改変&アダルト作品&商用利用の可不可、クレジット表記の要不要等の要点にまとめた規約になってることが多いし、規約を読みながらいろんな素材に触れておけば多少不備がある規約に遭遇しても「たぶんこう言いたいんやろな」というのは察せる -- 名無しさん (2023-10-14 10:38:23)
最終更新：2023年11月09日 08:55
