問題タブ [unity3d-gui]

899 という数字を表示するカウンターを作成し、数字が上に移動して 900 に移動するか、より単純に 7 がスクロール アウトして 8 がスクロール インするカウンターを作成したいと考えています。スクロールアウト効果を行うには？

シーン ビューでギズモ ( https://docs.unity3d.com/ScriptReference/Gizmos.html ) を描画することは可能ですか? シーン ビューのいくつかの UI 要素の概要を、バニラの Unity RectTransform がそこに示されているよりも完全に示したいと考えています。

https://docs.unity3d.com/ScriptReference/Gizmos.DrawGUITexture.htmlの使用を検討しましたが、それは古いスタイルの UI レイアウトにフォールバックしているように見え、UI キャンバスが可能な複数の異なるレンダリング モードを考慮していません。に設定。

私は Unity エディターの拡張に非常に慣れていないため、階層内の選択されたオブジェクトを強調表示するこのスクリプトをまとめました。問題は、私がエディターにいて、スタック (シーン名) の一番上がツリーに表示されると、階層全体が見えなくなることです! 下にスクロールしてシーン名が見えなくなると、自動的に修正されます。何が起こっているのかをよりよく理解できるように、画像を添付しました。オブジェクトがたくさんある場合、この問題は軽微ですが、新しいシーンでは使用できません。

コンソールには、「オブジェクト参照がオブジェクトのインスタンスに設定されていません」と表示されます。

画像： 正常に機能しています

正常に機能していない

ご協力ありがとうございました！

私はいくつかの場所でこの質問をしましたが、まだ完全には理解していません。

プロジェクトでプレハブの深くネストされた階層を維持する最良の方法は何ですか? 小さい汎用コンポーネントで構成された GUI 画面がいくつかあるとします。簡単にするために、前者を「ビュー」、後者を「コンポーネント」と呼びましょう。ビューはセマンティクスを扱います (在庫ビュー、店舗ビューなど)。コンポーネントは構成可能ですが、ビジネス ロジックはまったく関連付けられていません (たとえば、ボタンはその OnTap コールバック/イベント ハンドラーのみを考慮します)。

ビューとコンポーネントの両方をネストできます。

GUI ビューは複数のシーンで再利用する必要があります。

Unity でのこのアプローチの主な問題は、ネストされた階層が一度プレハブに変換されると、次の (完全に作成されたがまだ有効な) 例のように、その子プレハブへの参照が失われるという事実です。

- storeView - UIViewHeader - UIHeaderLabel<Text> - UIList - UIListItem - UIThumbnail - UITitleLabel<Text> - UISubTitleLabel<Text> - UIPrimaryButton<Button> - ...

これらすべての小さな UI* コンポーネントを個別のプレハブに保持したいと考えていますが、別のシーンに簡単に追加できるように storeView プレハブも保持したいと考えています。残念ながら、storeView プレハブを作成するとすぐに、すべての UI* プレハブ参照が失われます。その場合、別のアプローチを試すことができます。コンテンツを含む storeView プレハブを用意する代わりに、空のままにして、次のいくつかのオプションのいずれかを選択します。

1. 動作を storeView にアタッチし、実行時に子プレハブをロードする
   • 短所：デザイナーのワークフローがより複雑になり、スクリプトが複雑になり、開発者の観点からもエラーが発生しやすくなる可能性があります
   • 長所: シーン間での storeView の再利用が容易になり、コンポーネント プレハブのスタイル設定やグローバルな変更が可能
2. storeView を空のプレハブとして保持し、それを必要とするすべてのシーンで再構築します
   • 短所: コンポーネントを手動で接続する必要があります。storeView 全体を誤って保存して、プレハブの参照を失うことは依然として簡単です。
   • 長所：コンポーネントのプレハブ参照が維持されることを保証し、ビュー間のわずかな違いを許容します（これらは構成レイヤーに属する必要があるため、実際には問題です）
3. storeView 全体をプレハブとして保存する
   • 短所: 拡張性が非常に高く、新しい機能や小さな UX の変更の繰り返しに時間がかかります (追加の QA、受け入れテストなど...)。
   • 長所：小規模なプロジェクトでうまく機能する、迅速で汚いソリューションです
4. Prefab Evolution などを使用する
   • 短所: パッケージは、ロードマップにある入れ子になったプレハブによって廃止されると思いますか? サードパーティのコードに依存する必要があり、十分な柔軟性がない可能性があります (意見はありますか?)
   • 長所：私が見た多くの（さまざまな）レビューから、いくつかは非常に肯定的でした. ただし、プロジェクトが複雑になるほど、これらのレビューは肯定的ではなくなります。
5. 大量のカスタム エディター スクリプトを作成します。
   • 短所: 時間がかかります。また、主にゲームを扱っている場合でも、プラットフォームによって提供されるべきもののように思えます。
   • 長所: 動作を完全に制御でき、開発者がデザイナーのフィードバックを得て改善できます。機能要件として実装、テスト、および設計者にとって使いやすいツールを持つことについて規律を守ることは、優れた設計慣行のように聞こえると主張する人もいるかもしれません (結果として、技術的負債が少なくなり、保守が容易になります)。

これが私の個人的な対理想主義的で非現実的な解決策です*：

コンポーネント化されたアーキテクチャを使用します。デフォルトでは、子のプレハブ参照が複雑なプレハブに格納されます。内部的には、モバイル (Cocoa) の UIView とサブビュー、または React のコンポーネント クラスまたはそれ以上の機能コンポーネント (React/Cycle/Elm/FRP と相性の良いもの) と考えてください (はい、これらのアプローチが非常に多くの点で異なることはわかっています。しかし、重要なのは構成可能性であり、機能的構成、デコレータなどによって達成されます...)。

• 短所：ここでの私の困難は、Unityの経験が不足していることに起因すると思います。より明白で、おそらく慣用的な解決策があります（親切にお願いしています:)）

• 長所：新しい機能のテストと反復がはるかに簡単になり、プレハブがより強力になり、その利点を失うことはありません（間違っている場合は訂正してください。私はまだ Unity に慣れています）

• Unity にすべてを期待しているとは思わないでください。ただし、その 1% が真実であっても、それは可能な方向性の 1 つです。

はっきりさせておきますが、これは Unity に関する暴言ではありません。以前にモバイル (ネイティブ) と Web で働いていた開発者として、Unity で解決できる問題の数と、これらのソリューションのいくつかが非常に単純であることに感銘を受けました。

私の状況では、配列InputFieldsがあります-6つの InputFields。各 InputField からテキストを取得して保存するにはどうすればよいですか?

すべてが次のように機能するはずです。アプリをオンにし、入力フィールドの 1 つ、2 つ、またはすべてを変更してから、アプリケーションをオフにします。もう一度オンにすると、入力フィールドは以前に書いた値である必要があります。

正しく動作するはずのコードがありますが、このコードは次のように動作します。ユーザーが最後に入力した値のみを取得し、それを最後の入力フィールドに書き込みます。

入力フィールドの配列 Unity で各入力フィールドをスクリプト コンポーネントのフリー セルにドラッグして初期化します。

どうすればできremove border for input fieldますか？または、非表示にしたり、色を変更したりできますか? Google でこの質問に対する答えが見つかりませんでした。インスペクタで境界線の色を変更しようとしましたが、変更されませんでした。お願い助けて。