Suka banget sama postingan kamu.

EDIT:
Sialan mengabaikan paragraf ini

Miliki cara untuk benar-benar menyalin file ke dalam proyek jika modifikasi pada tingkat sumber diinginkan. Hanya dengan begitu file harus dibawa ke folder proyek itu sendiri. Aset "Kloning" dapat berada di folder tersembunyi seperti .custom.

Jadi pada dasarnya Anda telah menutupi kekhawatiran yang saya miliki. (maaf)
Saya hanya membahas lebih dalam bagaimana saya membayangkan alur kerja + perilakunya.

POS:
Satu alur kerja diabaikan IMO sekalipun.
Menggunakan aset hanya sebagai sumber daya atau batu bangunan pertama.
Pendekatan yang sangat transparan dan sederhana saat ini juga memungkinkan Anda mengunduh beberapa aset. menghapus beberapa file. Daripada menyimpan beberapa png dan skrip yang memiliki beberapa fungsi yang Anda inginkan di dalamnya. Saat ini dimungkinkan untuk hanya mengerjakannya dan memodifikasinya.

Jika aset disembunyikan di folder .local/godot/assets , fungsi ini akan hilang.

Usul

Aset harus tetap terlihat dan terdaftar di browser file editor. Independen jika mereka berada di dalam folder .local/godot/assets atau folder proyek itu sendiri. Jadi Anda dapat menelusuri file dan memahami cara kerjanya jika tidak ada dokumentasi yang tepat, atau jika Anda ingin belajar darinya.
Setiap Folder yang merupakan 'Aset' juga harus ditandai sebagai satu dengan semacam ikon sehingga Anda memiliki gambaran umum apa itu aset dan di mana file sebenarnya disimpan.
Seharusnya juga ada jendela editor yang mencantumkan semua aset. (dalam sebuah tabel)

• Diunduh mencantumkan semua aset yang diunduh. Mereka dapat ditambahkan ke proyek Anda dengan mengklik tombol. Tapi selain itu mereka sama dengan aset di aset lib. Daftar ini sama di setiap proyek dan tidak berpengaruh pada proyek itu sendiri. (hanya memudahkan untuk mendapatkan gambaran umum. juga mudah untuk menghapus daftar ini dan mengunduh ulang semua aset saat membuka proyek.)
• Selalu aktif (pada dasarnya hanya mengaktifkan "Digunakan dalam Proyek ini (aktif/tidak aktif)" untuk setiap proyek) Aset tersebut ditambahkan ke SETIAP PROYEK di mesin Anda (bahkan yang baru dibuat). (Mungkin aset itu sendiri perlu mengizinkannya.) Itu benar-benar berorientasi Editor. Seperti jam di sudut, dukungan git, daftar tugas atau untuk memiliki beberapa sumber daya default lagi: (lingkungan khusus beberapa tema lagi dan sekelompok sprite untuk digunakan di awal setiap proyek)...
  Mereka dapat dinonaktifkan secara manual per proyek.
  Mereka masih terdaftar dalam sistem file proyek dan berperilaku seperti plugin/assed lainnya. sehingga Anda dapat menelusuri file mereka dan melihat bagaimana mereka bekerja/apa yang mereka lakukan.
• Digunakan dalam Proyek ini (aktif/tidak aktif) ini sebenarnya menunjukkan folder tertaut dalam sistem file proyek. dan "menambahkan" (mereka masih berada di dalam folder .local/godot/assets , tetapi berperilaku seperti file lokal proyek.) file ke proyek.
  Di sini Anda juga dapat memilih versi Aset yang ingin Anda aktifkan. Dan ganti versi.

Segera setelah Anda ingin mengedit/menyimpan/memperbarui file dari Aset, Anda akan diminta dengan dua opsi

Hemat di .local/godot/assets

perbarui aset di .local/godot/assets yang memasukkannya ke dalam versi pengguna khusus.
Jika manajer paket berbasis git, versi pengguna khusus dapat menjadi salah satu komit tambahan. yang mendapat commit --amend ed setiap kali Anda menyimpan.
( 3.2.5/user misalnya) dan juga tersedia di semua proyek Anda yang lain. (saat memperbarui versi di proyek lain itu ke versi pengguna Anda)
mengapa ini berguna?
Tema dari toko aset hampir sempurna, tetapi Anda membenci jenis font...
ubah jenis font simpan sebagai versi aset baru. Kunjungi kembali semua proyek Anda yang lain dan ubah versi aset ke /user . Sekarang kamu bahagia.
Mungkin juga ada satu tombol untuk mempublikasikan aset versi pengguna.
Jadi di toko aset ppl lain memiliki opsi untuk juga memilih versi pengguna dengan sedikit penyesuaian.
Sama seperti perantara untuk membuat pr ke aset git repo. (atau penulis aset memutuskan untuk memilih perubahan dari versi /user ke versi baru di master.)

Jadikan lokal untuk proyek

menyalin file dari folder .local/godot/assets ke dalam proyek saat ini... menghapus semua perilaku aset khusus (seperti versi...) dan sekarang Anda dapat mengacaukannya sesuka Anda. (juga folder kehilangan tampilan kustomnya sebagai aset.)

Ini memungkinkan penyimpanan aset juga mencakup kasus penggunaan template. Dan merupakan pilihan sempurna untuk hampir semua aset terkait seni. Karena Anda dapat mengerjakan aset untuk membuatnya sesuai kebutuhan.
Anda selalu dapat mengaktifkan sekelompok aset yang sudah diunduh (katakanlah beberapa sprite prototipe dasar) menjadikannya lokal dan Anda telah mengimpornya.

pikiran acak

Ini bahkan mungkin menjadi solusi yang bagus untuk lib/koleksi aset/sumber daya lokal Anda sendiri. Folder di .local/godot/assets memungkinkan Anda menambahkan kontennya ke proyek Godot mana pun dengan ui editor yang bagus dan tanpa mencarinya di pengelola file OS Anda.

Saya setuju bahwa baik integrasi AssetLib maupun aset lib (baik di editor dan dengan GDScript) membutuhkan cinta jika kita terus mendorongnya sebagai alternatif untuk memasukkan hal-hal di mesin inti.

Namun, saya pribadi tidak setuju dengan seberapa berat plugin ini harus didorong.

Pertanyaan pertama yang kami ajukan pada diri sendiri tentang PR baru, bukankah ini bisa menjadi plugin? tetapi apakah ini akan cukup digunakan untuk menjadi inti? .

Ada masalah dengan memiliki sesuatu di plugin:

• Orang-orang perlu tahu apa yang mereka cari sejak awal. Godot ditargetkan untuk pemula . Perangkat lunak yang ramah pemula biasanya mencoba untuk memiliki semua yang seseorang akan (cukup) butuhkan, karena jika tidak, mereka harus terlebih dahulu mempelajari apa yang mereka lewatkan dan bagaimana mereka akan mendapatkannya.
  Ada alasan mengapa pemula menggunakan Ubuntu, bukan Gentoo. Terlepas dari seberapa baik Anda membuat sistem ketergantungan itu.
• Kelumpuhan keputusan ada. Jika ada fitur di Godot, bagus, butuh beberapa detik untuk menggunakannya. Jika ada 5 plugin untuk itu, mana yang akan saya gunakan? Misalnya, ada 5+ plugin konsol . Mana yang harus dipilih pemula, dan mengapa, dan berapa banyak waktu yang harus mereka habiskan untuk keputusan ini?
• Plugin ditinggalkan, kualitasnya kurang, tertinggal saat diperbarui. Bahkan ada lebih sedikit alasan untuk mempercayai plugin acak yang tidak akan meledak pada saya daripada mempercayai Godot, di mana ada cukup banyak orang di belakangnya.
• Lihat Kesatuan . Aset mereka sebagian besar bahkan dibayar , dan masih menyebalkan bahwa untuk banyak hal Anda memerlukan plugin terlebih dahulu yang akhirnya terintegrasi dengan buruk atau rusak saat pembaruan - atau dihentikan, meskipun mereka dibayar dan biasanya mampu membeli setidaknya beberapa dukungan.
• Dokumentasi : Kami tidak memiliki cukup ini. Setiap fitur tidak dalam inti, saya tidak dapat menggunakan dalam tutorial/dokumen resmi. Orang lajang acak untuk plugin kemungkinan tidak akan memberikan dokumen, atau hanya contoh singkat, bukan bagian yang lebih berharga dari menyediakan demo atau tutorial lengkap tentang cara mengintegrasikan fitur itu dengan orang lain secara mulus dalam sebuah proyek.

Contoh:

• Node lengan pegas. (https://github.com/godotengine/godot/pull/18822) Penambahan yang cukup kecil, dipisahkan ke dalam kelasnya sendiri sehingga tidak boleh merusak barang, akan digunakan oleh banyak game 3D, jika tidak oleh setiap game orang ketiga . Tanggapan: harus berupa plugin.
• Bahkan untuk hal-hal RNG, dibahas untuk menjadikannya sebagai plugin. Seolah-olah tidak 90% dari game membutuhkan RNG di suatu tempat.

Sunting: Agar jelas, saya semua untuk menghindari mengasapi. Tapi ini adalah keseimbangan, dan saya ingin menyuarakan dukungan karena tidak memiliki segalanya di plugin. Hal-hal yang sangat spesifik untuk game atau tidak digunakan secara luas, plugin berpemilik, dependensi besar, ya tolong , letakkan di Asset Lib!

@karroffel Ini adalah posting yang sangat bagus dan saya sebagian besar setuju dengan semua yang Anda katakan. Namun, saya ingin mengomentari poin ini:

Aset disimpan dengan versi yang terkait, semua disimpan di .local/godot/assets atau semacamnya. Mereka tidak lagi menjadi bagian dari proyek itu sendiri tetapi tersedia di seluruh sistem.

Ini mirip dengan cara kerja sistem pip Python. Orang-orang kemudian menyadari bahwa versi terbaru dari sebuah paket mengacaukan proyek lain yang Anda miliki di sistem Anda. virtualenv memecahkan masalah itu. Dalam ekosistem npm Javascript, modul diinstal secara lokal ke proyek secara default dan seluruh sistem adalah fitur keikutsertaan ( npm install --global ). Anda kemudian memeriksa package-lock.json Anda ke kontrol sumber untuk memastikan semua orang di tim menggunakan versi yang sama dari setiap modul npm dan menghindari konflik.

Paket seluruh sistem bagus karena mengurangi kembung pada sistem orang. Penyematan versi bagus karena membantu tim menjaga kumpulan versi yang konsisten dan dapat membantu Anda mengidentifikasi kumpulan lengkap versi yang bekerja sama dengan baik.

Jika kita menggunakan rute lebar sistem, saya sarankan untuk tetap memasang pin versi. Sebagai contoh:

.local/godot/assets/fsm/1.0
.local/godot/assets/fsm/1.1

Proyek A dapat menggunakan fsm-1.0 sementara Proyek B menggunakan fsm-1.1. Proyek C datang dan dapat digunakan kembali. Pengguna harus dapat menentukan versi plugin tertentu dalam file dependencies.json mereka atau patch minimum, versi minor atau mayor.

Setelah dependensi diunduh, file dependencies-lock.json dapat dibuat dan diperiksa ke kontrol sumber.

@mhilbrunner Saya sangat setuju, saya pikir mentalitas "ini harus menjadi plugin" didorong terlalu keras, persis situasi itu memicu pemikiran itu. Saya pikir hal-hal yang lebih umum seperti SpringArm layak berada di mesin, serta InterpolatedCamera , yang ingin dihapus Juan, sangat berguna dan keren! Meskipun hal-hal itu hanya beberapa baris kode, mereka membutuhkan waktu untuk memperbaikinya, jadi "ini terlalu kecil" juga merupakan pembenaran yang buruk untuk mendorong ke arah AssetLibrary.

Pikiran saya sebagian besar terpusat pada "Yah, pemimpin proyek mengatakan seperti itu, jadi apa yang bisa dilakukan untuk membuat situasi baru menjadi lebih baik?"

Saya ingin jika dorongan berat fitur sebagai plugin akan diturunkan sedikit, tetapi bagaimanapun saya pikir perubahan yang disajikan akan banyak membantu!

@saltares Ya itu pikiran saya. Saya penggemar berat kargo untuk Rust. Ini beroperasi hampir sama. Pustaka dipasang di folder lebar sistem di semua versi yang pernah dibutuhkan secara lokal. Deskripsi ada dalam satu file dan konfigurasi spesifik ada dalam file .lock , ini bekerja dengan sangat baik!

Saya senang ini sudah memicu beberapa diskusi :blush:

Berikut pandangan saya terhadap poin-poin di atas:

Mendorong barang keluar dari mesin

Mendorong barang-barang di luar mesin adalah cara yang harus dilakukan IMO. Ada terlalu banyak platform di mana masalah ukuran penyebaran (seluler, html5) dan mengasapi adalah masalah besar untuk proyek seukuran Godot, jadi kami tidak bisa begitu saja memasukkan semuanya.

Filosofi bagi saya adalah bahwa sesuatu harus menjadi bagian dari mesin hanya jika SEMUA kriteria di bawah ini terpenuhi:

1. Ini relatif sering digunakan
2. Susah buat sendiri
3. Hanya ada satu cara untuk melakukan fitur ini

Ini mengesampingkan lengan pegas, medan, dan saya harap ini dapat membantu, di masa mendatang, menghapus fitur seperti InterpolatedCamera, Vehicle, dll. yang menurut saya seharusnya berada di luar mesin.

Kekhawatiran utama tentang ini adalah, jika ada sesuatu yang tidak resmi, itu tidak akan dipertahankan. Di sinilah kalian salah.

Tidak ada yang mengatakan hal-hal ini tidak boleh resmi, kami dapat memiliki repositori resmi untuk mereka dan mereka dapat menjadi ekstensi pihak pertama. Demo dipertahankan dengan cara ini dan mutakhir, jadi saya tidak mengerti mengapa itu tidak berfungsi untuk repo ekstensi resmi.

Ekstensi harus terasa seperti bagian dari mesin

Mengenai poin-poin ini:

• membuatnya lebih mudah untuk memperluas node khusus, memungkinkan pewarisan skrip lintas bahasa

Saya sangat menentang hal ini. Tidak ada manfaat praktis sama sekali untuk melakukan ini, dan biaya implementasinya sangat mahal. Maaf teman-teman, saya tahu rasanya fitur yang bagus untuk dimiliki tetapi pembobotan biaya/manfaat/risiko untuk itu ada di sisi yang sangat negatif.

Saya juga berpikir positif bahwa node atau sumber daya khusus akan muncul seolah-olah mereka BUKAN inti adalah hal yang baik untuk pengguna akhir. Pengguna tidak bodoh dan informasi ini tidak boleh disembunyikan untuk mereka.

Jika simpul baru ditambahkan dari ekstensi, dan selesai dengan skrip, ini harus ditampilkan dalam dialog buat.

• Warisan skrip tidak disarankan saat melampirkan skrip - penggantian adalah default untuk kasus tersebut.

Ini pasti perlu dilakukan dan akan menjadi tambahan yang sangat disambut.

• tambahkan manajemen ketergantungan yang tepat dengan pemasangan aset di seluruh sistem. Pindahkan add-on dari proyek itu sendiri dengan cara mengembalikannya untuk dimodifikasi

Perasaan saya tentang ini adalah bahwa itu dapat bekerja dengan fantastis, atau menghasilkan kekacauan total dan add-on yang rusak tanpa alasan yang jelas. Melihat bagaimana mesin lain bekerja dengan ini, sepertinya memiliki manajemen ketergantungan bagi saya tidak begitu penting.

• izinkan skrip direferensikan oleh nama kelas dan namespace untuk menghindari jalur super panjang jika ada aset.

Ini adalah sesuatu yang kami diskusikan sebelumnya, tetapi kesimpulan yang kami capai adalah bahwa itu sebagian besar harus bergantung pada bahasa skrip (dan tidak disediakan oleh mesin itu sendiri sebagai inti ScriptDB), dengan peningkatan kegunaan kecil dalam dialog skrip baru jika Anda ingin menggunakan kelas global.

Perasaan saya tentang ini adalah bahwa itu dapat bekerja dengan fantastis, atau menghasilkan kekacauan total dan add-on yang rusak tanpa alasan yang jelas.

Saya kira add-on tidak boleh diperbarui secara otomatis dalam kasus kami, tetapi sebaliknya mungkin harus ada daftar yang diinstal dengan versi yang terdaftar dan pembaruan manual, sehingga pengguna dapat meminta pembaruan dan segera memeriksa jika ada yang rusak.

Komentar ini dipisahkan menjadi beberapa bagian yang diciutkan karena panjangnya yang besar.

Ingin kamera? Godot punya kamera yang bisa mengikuti pemain, dengan sedikit atau tanpa kode dari Anda. Ingin membuat animasi di Godot? Anda tidak hanya dapat membuat animasi karakter, sistem yang sama dapat (hampir) menggantikan sistem cut-scene yang Anda kerjakan dengan sangat keras, hanya membutuhkan mungkin lima atau lebih baris kode dari Anda. Editor tersebut bahkan telah digunakan untuk membuat editor lain seperti RPG in a Box. Sungguh fantastis betapa banyak yang dapat Anda buat di Godot.

Sekarang dengan menyingkir, semoga siapa pun yang membaca ini dapat memahami apa yang saya pikirkan tentang ini ketika saya mencoba untuk menanggapi beberapa poin reduz tentang mendorong sesuatu keluar dari mesin. (Ini tidak akan membalas bagian "Ekstensi harus terasa seperti bagian dari mesin" karena saya tidak memikirkannya saat ini.)

Mendorong barang-barang di luar mesin adalah cara yang harus dilakukan IMO. Ada terlalu banyak platform di mana masalah ukuran penyebaran (seluler, html5) dan mengasapi adalah masalah besar untuk proyek seukuran Godot, jadi kami tidak bisa begitu saja memasukkan semuanya.

Saya dapat setuju bahwa mengasapi adalah masalah, tetapi ketika saya melihat apa yang ingin Anda hapus sejauh ini, saya bertanya pada diri sendiri apakah benar-benar layak untuk menghilangkannya. Bahkan jika Anda menghapus node seperti Vehicle, InterpolatedCamera, dll... Berapa banyak perbedaan ukuran file yang akan terjadi? Mungkin setengah megabyte? Mungkin beberapa megabyte? Bahkan jika itu menghemat beberapa megabyte, apa perbedaan antara unduhan 35MB dan unduhan 45MB? Aset game akan dengan cepat mengisi kekosongan 10MB itu! Kecuali Anda berencana melepas setengah mesin, saya tidak mengerti maksudnya.

Jika Anda benar-benar khawatir tentang menghemat ruang sebanyak mungkin, bolehkah saya menyarankan untuk mempermudah pengguna akhir untuk menghapus node yang tidak mereka perlukan dari mesin? Biarkan orang yang akan menggunakan mesin memutuskan apakah mereka baik-baik saja dengan kembung -- jangan memutuskan untuk mereka.

Sekarang tentu saja kita tidak bisa begitu saja memasukkan setiap saran yang diberikan kepada kita...

1. Ini relatif sering digunakan
2. Susah buat sendiri
3. Hanya ada satu cara untuk melakukan fitur ini

...dan pedoman ini adalah titik awal yang bagus untuk meneliti apa yang seharusnya diperbolehkan di dalam mesin. Tidak diragukan lagi bahwa ketiga poin tersebut telah dipertimbangkan untuk setiap permintaan fitur yang datang melalui pelacak masalah.

sesuatu harus menjadi bagian dari mesin hanya jika SEMUA kriteria di bawah ini terpenuhi

Tapi ayolah. Nasib fitur atau simpul tidak boleh terlalu bergantung pada fitur inti. Pedoman yang Anda sarankan sangat bagus, jangan salah paham, tetapi kita tidak boleh menggunakannya sebagai daftar periksa. Itulah yang YoYo Games lakukan ketika Anda menyarankan fitur di forum mereka, dan merupakan bagian lain dari alasan saya disingkirkan dari mesin mereka -- dapatkah fitur itu dibuat menggunakan ekstensi? Ya? Kemudian tanggapan kami adalah membuat ekstensi. Tebak berapa banyak permintaan fitur yang telah ditolak karena mereka dapat dibuat menjadi ekstensi, terlepas dari seberapa masuk akal jika itu ada di mesin, seberapa mudah dibandingkan dengan penerapannya, atau bagaimana perasaan komunitas tentang fitur itu.

Apa yang saya katakan adalah bahwa Anda pasti dapat mengingat pedoman itu. Anda dapat mempertimbangkannya setiap kali fitur disarankan. Tetapi apakah semuanya berlaku BUKAN menjadi faktor penentu masuk atau tidaknya suatu fitur. Timbang ide dengan pedoman tersebut, pertimbangkan seberapa penting masing-masing pedoman itu dan terapkan bobot pada faktor-faktor tersebut... Hanya karena sebuah ide tidak sepertinya terlalu sering digunakan tidak secara otomatis menjadikannya ide yang buruk (perlu diingat bahwa Anda mungkin tidak mengetahui skala sebenarnya dari cara penggunaannya, bahkan dengan pengalaman beberapa tahun). Hanya karena sebuah ide mudah diterapkan sendiri tidak secara otomatis berarti itu ide yang buruk. Dan hanya karena kita dapat mengimplementasikan sebuah ide dengan lebih dari satu cara bukan berarti itu ide yang buruk! Belum lagi mungkin seseorang menyarankan ide X karena mereka pikir orang lain akan mendapat manfaat darinya.

Ingatlah bahwa ini adalah mesin yang menyebut dirinya sebagai ramah pemula, dan setiap kali seorang pemula harus mengkodekan sesuatu yang tidak spesifik untuk permainan mereka yang bukan bagian dari mesin, atau lihat di beberapa perpustakaan aset untuk mendapatkan kode yang mereka butuhkan , atau menempuh rute panjang untuk mendapatkan apa yang mereka inginkan dari mesin, itu bisa mendorong mereka sedikit lebih jauh ke mesin lain, atau kadang-kadang bahkan menjauh dari pengembangan game secara keseluruhan.

tl;dr : Pedoman sangat bagus ketika digunakan sebagai pedoman dan bukan daftar periksa.

Kekhawatiran utama tentang ini adalah, jika ada sesuatu yang tidak resmi, itu tidak akan dipertahankan. Di sinilah kalian salah.

Tidak ada yang mengatakan hal-hal ini tidak boleh resmi, kami dapat memiliki repositori resmi untuk mereka dan mereka dapat menjadi ekstensi pihak pertama. Demo dipertahankan dengan cara ini dan mutakhir, jadi saya tidak mengerti mengapa itu tidak berfungsi untuk repo ekstensi resmi.

Saya pribadi tidak setuju dengan ide ini. Bersamaan dengan apa yang saya katakan di atas (bahwa menghapusnya dari mesin vanilla tidak akan menghemat banyak ruang), saya harus bertanya apakah kita akan mengonversi semuanya ke GDscript, atau apakah kita akan membutuhkan mereka untuk mengkompilasi ulang mesin hanya untuk mendapatkan node tersebut.

• Jika kita menyimpannya sebagai C++ dan memerlukan kompilasi ulang... mengapa? Tidak ada alasan yang baik kita harus pernah diminta untuk mengkompilasi ulang mesin kecuali kita mengubah bagian inti darinya, atau menambahkan fungsionalitas kita sendiri. Itu hanya waktu tambahan yang diambil dari pengembangan, karena kami menunggu proses kompilasi selesai, di samping mengharuskan rata-rata pengguna untuk menginstal alat lain yang mungkin tidak akan mereka gunakan lagi hanya untuk mendapatkan beberapa node pihak pertama. Sekarang kedengarannya seperti kembung!

• Jika kita mengonversinya ke GDscript, maka itu akan datang dengan semua keterbatasan GDscript. Keterbatasan seperti potensi overhead node anak tambahan (terutama jika Anda meminta pengguna untuk mengimpor node pihak pertama ini sebagai adegan), harus menggunakan jalur daripada nama kelas untuk merujuk ke kelas mereka (meskipun Anda membahas ini, itu sepertinya, tapi saya merasa saya perlu mengangkatnya), kinerja yang lebih rendah (terlepas dari seberapa kecil perbedaannya, itu masih lebih rendah), dll. Ini sedikit lebih ideal daripada C++ karena Anda telah beralih dari kompilasi ulang ke seret-n-jatuhkan, tapi...

Pilihan mana pun juga berarti file untuk node ini harus diimpor ke mesin dengan setiap pengguna baru (untuk C++) atau ke folder proyek dengan setiap proyek baru (untuk GDscript) yang ingin menggunakannya. Saya tidak tahu tentang orang lain, tetapi itu terdengar merepotkan bagi saya, dan sepertinya itu akan membuat pedoman pertama Anda ("Ini relatif sering digunakan") sangat bisa diperdebatkan. Saya akan mencoba menjelaskan mengapa saya berpikir demikian.

Dengan memerlukan upaya tambahan untuk menggunakan node tersebut, saya cukup yakin jumlah penggunaan solusi pihak pertama ini akan turun, dan solusi pihak pertama ini benar-benar tidak akan lagi digunakan "relatif sering" di tempat sebelumnya. Itu, pada gilirannya, perlahan-lahan akan meningkatkan jumlah alternatif yang membuat ulang fitur yang sama ketika orang berhenti belajar ada solusi pihak pertama -- ketika saya cukup yakin kami lebih memilih versi yang ada (dalam hal ini, milik kami) daripada ditingkatkan, daripada membuat yang baru dengan fitur X ditambahkan, yang baru dengan Fitur Y, dan yang baru dengan kedua fitur tersebut tetapi tidak dioptimalkan, dan seterusnya... Ini menciptakan pasar untuk alternatif ketika orang tidak tahu ada solusi pihak pertama. Ini menciptakan kekacauan .

Selain itu, Anda mengatakan mereka akan tetap dipertahankan. Itu keren! Tapi siapa yang akan memelihara mereka? Apa pedoman kami untuk menambahkan hal-hal baru ke repositori ini? Dan apakah kita akan berusaha memastikan repositori ekstensi pihak pertama ini akan selalu berfungsi, baik dengan rilis stabil atau dengan master? Pada dasarnya, apakah sepadan dengan usaha yang secara efektif merupakan proyek terpisah?

omong-omong, saya lebih suka mengimplementasikan banyak skrip per simpul dukungan
daripada pewarisan lintas bahasa. Yang pertama hanya beberapa baris
dari kode..

Pada Minggu, 10 Jun 2018 pukul 13:51 Plyczkowski [email protected] menulis:

Perasaan saya tentang ini adalah bahwa itu dapat bekerja dengan fantastis, atau menghasilkan
kekacauan lengkap dan add-on yang rusak tanpa alasan yang jelas.

Saya kira add-on tidak boleh diperbarui secara otomatis dalam kasus kami, tetapi
alih-alih mungkin ada daftar yang diinstal dengan versi yang terdaftar
dan pembaruan manual, sehingga pengguna dapat meminta pembaruan dan segera memeriksa apakah
ada yang rusak.

—
Anda menerima ini karena Anda berkomentar.

Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-396063688 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AF-Z21jtcnUhRyhdyEEnaM_hfTACsxOiks5t7U6HgaJpZM4UhqDC
.

Beberapa skrip per node telah dicoba beberapa kali dan selalu gagal.

apa yang dicoba adalah node multiscript, tapi itu merepotkan

Pada Minggu, 10 Jun 2018 pukul 15:01 Zireael07 [email protected] menulis:

Beberapa skrip per node telah dicoba beberapa kali dan selalu
kegagalan.

—
Anda menerima ini karena Anda berkomentar.

Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-396068742 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AF-Z26u8Rqc1yL-BGX16CAx_iWsYEo1oks5t7V8CgaJpZM4UhqDC
.

Saya mengerti bahwa aset tidak boleh terlihat sama dengan barang bawaan. Tapi saya juga berpikir mereka harus berada di kelas yang lebih tinggi daripada skrip buatan pengguna. Mereka harus memiliki pemisahan yang jelas sehingga mudah untuk mengganti/meningkatkan aset tanpa harus menambangnya dari proyek Anda.

Selain itu, menambahkan lapisan untuk aset dan membiarkannya berintegrasi lebih baik dengan mesin untuk memperluasnya adalah cara yang bagus untuk menjaga inti tetap kecil dan bersih, sambil menyediakan fungsionalitas baru dengan mudah melalui pustaka aset. Jika aset dapat mendaftarkan tipe baru tidak hanya untuk node/sumber daya, tetapi juga kelas yang akan diperluas, dengan cara yang dapat diakses secara global (yaitu tidak bergantung pada jalur), akan sangat bermanfaat bagi kerangka kerja untuk membangun di atas mesin.

Kerangka kerja seperti Escoria bisa mendapat banyak manfaat darinya, dan mungkin ada kerangka kerja lain untuk hal-hal seperti RPG, platformer, novel visual, dll.

Semua yang saya katakan di sini cukup abstrak, tetapi memiliki pemisahan yang jelas tentang apa yang ada di dalamnya, apa aset pihak ketiga, dan apa itu kode pengguna (namun pemisahan ini disajikan) akan membuat "pertahankan inti tetap kecil dan berikan ekstensi "maju dengan mudah.

Warisan lintas bahasa terdengar seperti ide yang mengerikan bagi saya.

Dalam pekerjaan yang saya lakukan dengan TypeDB di EditorData, saya telah menyimpan namespaced-typename ke filepath HashMap yang akan dikonversi ke Kamus di ProjectSettings setelah modifikasi. Di cabang saya, pengurai dan kompiler GDScript menggunakan data ini untuk membuat nama global untuk tipe. Saat ini, saya memiliki skrip tipe khusus yang muncul. Skrip dapat mengakses dan mewarisinya berdasarkan nama. Terlebih lagi, data ini dapat diakses oleh apa pun yang dapat melihat ProjectSettings. Jadi CSharpScript yang dilihat oleh Editor dapat menghasilkan pemetaan yang dimasukkan ke Kamus ProjectSettings, memungkinkan jenis yang dideklarasikan dalam C# dapat diakses ke GDScript. Mungkin juga ada cara untuk membungkus data Kamus ProjectSettings dalam Objek C# yang mengembalikan objek Skrip saat diakses, dengan cara itu C# juga dapat mengakses tipe GDScript berdasarkan nama.

Teknik ini membuat ruang nama bersama keluar dari inti dan murni dalam konteks Editor, di mana bahasa yang ikut serta dapat menyiapkan cara mereka sendiri untuk mengakses data.

Saya suka saran @ karroffel untuk dapat memiliki pewarisan skrip lintas bahasa (bahkan tidak tahu apakah itu mungkin). Entah bagaimana secara otomatis menduplikasi metode yang mendelegasikan panggilan ke skrip dasar dan juga mendefinisikan semua properti/sinyal/konstanta yang sama, dll.

Saya juga menginginkan akses yang lebih ramping ke konten di AssetLibrary, dengan kemampuan untuk menyimpan beberapa plugin untuk editor secara keseluruhan dan plugin lain hanya untuk satu proyek.

Sistem TypeDB yang saya buat juga akan memberikan dukungan editor untuk...

1. Menampilkan semua skrip khusus seseorang di CreateDialog
2. Memperluas skrip tipe khusus secara otomatis membuat Anda memperluas skrip itu saat menambahkan skrip ke node
3. Menghapus skrip yang memperluas skrip jenis khusus, memulihkan skrip jenis khusus setelah dihapus (sehingga Anda tidak dapat menghapus skrip khusus - Anda harus menggunakan perintah "Ubah Jenis" di Editor sebagai gantinya).

Juga, semua perubahan antarmuka yang saya buat akan membuat skrip jenis khusus dipahami dengan jelas sebagai skrip serta menjaga skrip yang dimaksud tetap dapat diakses. Pengguna akan selalu tahu apa itu skrip dan mengizinkan mereka mengakses skrip, tetapi itu masih membuat mereka merasa seperti objek di dalam mesin sampai batas tertentu. Bahkan di dalam GDScript, nama-nama tersebut tidak diakses secara global, seolah-olah mereka adalah tipe inti, melainkan diekstraksi dari Kamus global yang disebut Scripts . Sejauh ini saya membuatnya bekerja dengan skrip tipe khusus, tetapi saya akhirnya ingin memperluas agar Kamus mendaftarkan adegan tipe kustom dan skrip atau adegan khas apa pun yang tersedia di proyek juga, kemungkinan melalui sistem Impor jika bahasa skrip tidak memiliki cara sederhana untuk memperoleh namespaced typename.

Karena saya telah menjadi bagian dari proses pemikiran proposal ini, saya ingin menunjukkan beberapa hal:

Visi saya tentang Godot

TLDR: Saya membayangkan Godot sebagai alat yang dapat diperluas dengan aset dan plugin dengan cara yang sangat mudah, modular, dan ramah bagi pemula.

Motif di balik penolakan pr SpringArm saya lebih dari wajar, dan itulah sebabnya saya dan @karroffel membahas tentang arah yang dapat diambil mesin untuk tetap ringan dan, pada saat yang sama, ramah pengguna.

Yang ingin saya lihat adalah mesin inti yang bersih, kecil dan cepat, serta ekosistem add-on dan plugin yang terintegrasi dengan baik.
Karena ArchLinux memiliki lebih dari satu repositori paket, saya pikir akan sangat bagus jika Godot memiliki repositori "resmi" (dikelola oleh Godot) untuk fungsionalitas inti (dan Node yang sekarang menjadi inti) dan repositori lain untuk komunitas. Dalam "repositori ekstensi" inti Godot saya akan meletakkan semua node yang sulit untuk dikodekan tetapi tidak cukup digunakan untuk dikirimkan dengan versi Vanilla dari Engine.
Catatan tambahan, apa yang sering tidak diperhitungkan adalah bahwa beberapa fitur mungkin mudah untuk dikodekan tetapi mungkin juga memerlukan banyak penelitian sebelum meletakkan beberapa baris ini.

Saya membayangkan pengguna dapat mengunduh plugin dan aset yang terasa seperti mereka "memperpanjang" mesin itu sendiri: tergantung pada apa yang Anda unduh, Anda memiliki Godot-fps atau Godot-platformer atau Godot-racing.

Godot bisa menjadi mesin pertama yang terasa benar-benar mirip Unix dan modular, bahkan melebihi Unity dengan ekstensi editornya. Banyak dari Anda tahu betapa enaknya ketika sistem Linux Anda bukan "distro itu", itu adalah sistem Anda sendiri dan disesuaikan dengan fungsionalitas yang sangat pribadi Anda.

Keuntungan

TLDR: pendekatan ini akan memungkinkan manajemen Godot untuk mengelola fitur inti teknis hardcore secara terpisah dan lebih banyak plugin yang ramah pengguna tanpa terlalu khawatir tentang pembengkakan mesin

Apa yang baik dari proposal ini juga adalah pemisahan perhatian dan penanganan kontributor. Saya merasa, untuk saat ini, tidak jelas apa yang boleh berada di inti dan apa yang tidak. Tidak ada aturan yang jelas atau data statistik untuk dibicarakan. Beberapa orang mungkin mengatakan fitur tertentu digunakan secara luas dan beberapa lainnya berpikir tidak.

Membagi Godot dalam "cincin" yang berbeda memberikan kesempatan untuk manajemen PR dan fitur yang lebih halus, dan dapat memberikan lebih banyak waktu kepada @reduz dan pengembang yang sangat teknis lainnya untuk fokus pada hal-hal teknis hardcore , sementara tim lain akan mengelola cincin ekstensi, lebih mempertimbangkan umpan balik pengguna dan kegunaan daripada harus menghadapi mesin kembung, karena "cincin ekstensi" akan mengasapi sesuai permintaan.

Tentang pewarisan multibahasa

Saat Godot tumbuh, toko aset dapat dengan mudah menjadi kekacauan yang menyala-nyala. Pembagian yang ketat antara bahasa scripting benar-benar dapat menghancurkan segala upaya yang dilakukan orang untuk menjual aset dan menumbuhkan ekosistem di toko aset, membunuh banyak peluang bagi pembuat alat lepas untuk membuat dan menjual alat untuk Godot.
Jembatan bahasa perlu lebih lengkap jika kita ingin ada peluang untuk mengembangkan ekosistem yang hidup.
Untuk saat ini warisan lintas bahasa terdengar bagus bagi saya, tetapi saya tidak cukup teknis untuk mengatakan apa pun tentang masalah ini. Saya hanya ingin menunjukkan masalah yang kemungkinan akan segera muncul, terutama karena ada komunitas besar di sekitar C#.

Catatan tentang kegunaan

Saya telah menggunakan Godot selama hampir satu tahun sekarang, dan akhir-akhir ini saya merasa bahwa orang yang memutuskan tentang fitur tidak menggunakan mesin untuk sesuatu yang lebih besar dari demo kecil. @LikeLakers2 menunjukkan masalah yang saya rasa dibagikan oleh beberapa pengguna yang tidak mendalami tim inti yang sedang berkembang.

Saya pikir apa yang dianggap mengasapi adalah topik sepele dalam skema yang lebih besar, itu tidak seperti keputusan yang kita buat sekarang adalah apa yang harus kita patuhi sepanjang hidup Godot. Menjadi open-source memungkinkan kita untuk membuat perubahan kapan pun kita suka, satu-satunya masalah adalah semakin kita menunggu, semakin berat keputusan perubahannya.

Nah itu juga diskusi untuk hari lain. Saat ini faktanya adalah,

1. Godot adalah mesin game yang ringkas, cepat, dan portabel. Dan saya sangat menyukainya tapi, ....
2. Eksekusi Godot adalah sekitar 45-60MB tergantung pada berbagai faktor. Tapi template ekspor bisa sebesar 300MB. Nah, itu pukulan besar untuk poin pertama.
3. Godot memiliki banyak fitur luar biasa yang menjadikannya suguhan untuk pemula seperti Camera follow, Parallax BG, dan Vehicles, ini merupakan nilai tambah yang besar dibandingkan mesin game serupa lainnya. Karena membuat game jauh lebih sederhana di Godot. Dan menjadikan Godot rumah bagi banyak pengembang pemula, yang tidak memiliki keterampilan untuk menulis implementasi mereka sendiri untuk alat tersebut.

Sekarang apa yang akan terjadi jika kita menghapus fitur yang beberapa orang anggap mengasapi. Yah mesinnya pasti akan lebih kompak tetapi apakah itu diperlukan? Saya tidak melihat masalah dengan diri saya sendiri mengunduh Mesin 100MB jika memenuhi kebutuhan saya dengan lebih baik. Tapi bagaimana dengan mengekspor, bukankah mesin 100MB akan mengekspor game yang lebih besar?

Mungkin, ya, tetapi di dunia di mana desktop tampaknya tidak menggunakan apa pun yang kurang dari 256BG SSD + 1TB HDD dan bahkan Telepon memiliki ruang mulai dari minimal 16GB yang semuanya kemungkinan besar akan meningkat , apakah itu BURUK?
Maksud saya, kita belum perlu menghapus apa pun, kita hanya perlu mulai mengelola beberapa hal dengan lebih baik dan itu saja.
Fitur harus memiliki semacam daftar kepentingan untuk diputuskan apakah mereka seharusnya menjadi inti atau tidak, tetapi itu tidak berarti bahwa itu menjadi undang-undang melainkan aturan praktis.

Dan untuk pemetik nit kita bisa menghapus beberapa alat yang sangat tidak terpakai tapi hanya itu. Fitur tidak mengasapi mesin kecuali kita ceroboh. Dan bahkan semua kembung di Unity tidak menghentikan orang untuk menggunakannya, bukan.
Dan saya sama sekali tidak bermaksud bahwa kita tidak boleh peduli tentang kembung, tetapi berhati-hati dan menjadi paranoid adalah hal yang berbeda.

Adapun warisan multi-bahasa, saya tidak benar-benar melihat gunanya di sini. Tentu kita harus dapat berinteraksi dengan skrip dari berbagai bahasa tetapi warisan! Itu mungkin lebih banyak pekerjaan daripada yang bisa saya bayangkan dengan manfaat yang sepertinya tidak sepadan.
Padahal, multi-skrip mungkin hanya solusi untuk banyak masalah, mulai dari pembuatan add-on hingga modularitas yang lebih baik. Meskipun itu adalah perspektif saya.

Ada sesuatu yang bisa dikatakan tentang membatasi jumlah node dan jenis sumber daya yang ada di dalam kotak. Dengan memindahkan aset yang jarang digunakan ke unduhan eksternal, Anda membuat 1. jauh lebih mudah bagi orang baru untuk menguasai sistem hanya dengan "Memain-mainkan" tanpa terbebani oleh luasnya fitur (kelumpuhan keputusan), dan 2. tidak berakhir dengan membuat bagasi warisan sebanyak-banyaknya jika ternyata beberapa aset skenario kasus penggunaan yang lebih sempit akhirnya memiliki alur kerja yang tidak sebagus sesuatu yang datang setelahnya dengan API yang berbeda.

Ketika yang terakhir terjadi dengan built-in, Anda terjebak dengan mereka. Ketika itu terjadi dengan aset yang dapat diunduh, yang paling populer cenderung menjadi standar de facto dari waktu ke waktu, tetapi tidak memiliki nasib yang secara permanen terkait dengan nasib Godot. Itu berarti mereka dapat memudar menjadi ketidakjelasan tanpa harus khawatir sebanyak melanggar kompatibilitas inti yang diharapkan.

Titik pewarisan lintas bahasa membutuhkan penjelasan. Tidak hanya saya menganggapnya sebagai ide yang buruk, tetapi saya bahkan tidak melihat bagaimana hal itu mungkin terjadi.

1. Eksekusi Godot adalah sekitar 45-60MB tergantung pada berbagai faktor. Tapi template ekspor bisa sebesar 300MB. Nah, itu pukulan besar untuk poin pertama.

300MB template ekspor? Apakah yang Anda maksud: aset

@neikeq masalahnya adalah jika seluruh proyek Anda dalam C # tetapi Anda menggunakan simpul khusus yang diunduh dari AssetLibrary maka Node itu hanyalah simpul biasa, kemungkinan besar hanya dengan GDScript yang terpasang.

Jika Anda ingin "memperpanjang" simpul, Anda tidak bisa! Saya kira Anda dapat menambahkan simpul anak untuk menambahkan fungsionalitas baru, tetapi dengan cara itu tidak mungkin untuk menimpa sesuatu.

Penerapan

Saat ini bahasa skrip menggunakan pola yang sangat mirip untuk panggilan yang diwariskan yang dapat digeneralisasi.

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdnative/nativescript/nativescript.cpp#L696 -L712

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdscript/gdscript.cpp#L638 -L651

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/mono/csharp_script.cpp#L1175 -L1191

Pola di sini adalah

Class *c = bottom;
while (c) {
    if (c->has_method(m)) {
        c->call(m);
        break;
    }
    c = c->base;
}

Jadi itu dimulai di bagian bawah pohon pewarisan skrip dan kemudian mencoba memanggil level atas jika tidak ada metode seperti itu yang ditemukan.

Jika setiap skrip memiliki Ref<Script> parent_script alih-alih struktur pewarisan khusus bahasa, ini dapat digeneralisasi ke

if (this_class->has_method(m)) {
    this_class->call(m);
} else {
    // method not declared here, go to base class
    parent_script->call(m);
}

Ini mungkin bukan ide yang baik, tetapi tidak memiliki opsi untuk menimpa hal-hal lintas bahasa mungkin menjadi masalah dari waktu ke waktu jika kita mendorong AssetLib lebih banyak.

@neikeq Lihat ini,

@swarnimarun Itu templat ekspor untuk semua platform, semua lengkungan yang didukung, debug, dan rilis, ukurannya sama sekali tidak relevan dengan "penggembungan" mesin. Kami dapat memutuskan untuk hanya mendukung rilis Linux X11 64-bit dan file ini akan berukuran 20 MB...

@akien-mga Saya tidak bermaksud menyebutnya, mengasapi.
Tetapi pengguna baru akan mengunduhnya dalam ukuran penuh, mereka tidak akan cukup berpengalaman untuk mengetahui bahwa mereka dapat membangun secara terpisah atau mengunduh untuk platform tertentu.

Bagaimana tidak relevan ketika ini yang kami berikan kepada pengguna pemula?

@akien-mga: Ukuran template ekspor penting karena argumen Anda untuk menghapus node adalah

menyebarkan masalah ukuran (seluler, html5)

@swarnimarun @Zireael07 Ya ukuran templat ekspor penting secara individual , tetapi maksud saya adalah mengukur ukuran bundel templat tidak memberi kita indikasi apa pun. Ukuran satu templat (mis. templat rilis wasm, 3,4 MB di-zip, atau APK rilis Android, 23 MB di-zip dengan armv7 dan x86 libs) jauh lebih relevan daripada "mengunduh semua yang diperlukan untuk mengembangkan membutuhkan 350 MB" (+ mungkin 10 GB untuk Visual Studio jika Anda perlu membangun sesuatu ...). Yang penting jika ukuran permainan minimal akan mengambil platform di mana ukuran penting (web, seluler).

Meskipun saya pikir ukuran penyebaran sangat penting, saya juga berpikir bahwa apa yang perlu diperhitungkan juga waktu pengembang. Misalnya, Unreal benar-benar memiliki fitur apa pun yang mungkin Anda cari, tetapi fakta bahwa ada begitu banyak fitur membuat proses pengembangan menjadi sangat tidak efisien karena setiap kali Anda perlu melakukan sesuatu dengannya, Anda harus terlebih dahulu mencari tahu fungsionalitas bawaan mana. perlu Anda gunakan dan kemudian pelajari cara menggunakannya dengan benar.

Ini adalah sesuatu yang sangat saya sukai dari Godot. Anda dapat langsung mengkodekan fitur Anda dan kemudian seseorang akan datang dan memberi tahu Anda "yo, tahukah Anda bahwa kami memiliki hal bawaan yang dapat Anda gunakan?"

Masalah ketika sebuah mesin memiliki terlalu banyak fitur secara bersamaan adalah bahwa berkembang dengan mesin itu menjadi pengalaman yang sangat melelahkan. Ya, menyenangkan memiliki semua fitur yang Anda butuhkan, tetapi sangat sulit untuk mempelajari semuanya untuk mencari tahu apa yang sebenarnya Anda butuhkan. Itu kembung. Dan itulah mengapa kami mengusulkan untuk memiliki fitur yang terintegrasi dengan baik sesuai permintaan.

tambahkan manajemen ketergantungan yang tepat dengan pemasangan aset di seluruh sistem. Pindahkan add-on dari proyek itu sendiri dengan cara mengembalikannya untuk dimodifikasi.

Ini sama dengan kehilangan portabilitas. Plugin saya adalah bagian dari proyek saya, saya membutuhkannya di komputer apa pun yang saya gunakan dan saya memerlukan modifikasi konkret dari setiap plugin untuk setiap proyek... Saya tidak melihat manfaat apa pun jika plugin saya disimpan di .local/whatever . Ini adalah jenis kebingungan proyek saya.

Sistem res://addons sebenarnya bagus... gratis untuk pengguna dan portabel di sekitar komputer. Jika tidak ada keluhan tentang sistem ini, apakah perlu untuk mengubahnya? Ada banyak hal lain yang benar-benar dikeluhkan pengguna...

@Ranoller Anda dapat setiap saat menyalin plugin ke folder game Anda.
Bagaimanapun, dalam hal ini project.godot Anda akan mencantumkan plugin Anda sebagai ketergantungan dan itu akan diunduh ke komputer baru Anda dengan versi yang benar

Diunduh? Plugin saya ada di dalam proyek yang ada di dalam flashdisk, dan merupakan bagian dari repositori git ... Saya tidak mengerti proposal ... Plugin mengubah kode yang sama dengan yang lain ... Saya mengubah lebih banyak kode dari plugin yang kode permainan, saya tidak ingin memberi nomor plugin berdasarkan versi dan bekerja di luar proyek... Setiap perubahan kode satu baris perlu secara manual mengubah setiap plugin di setiap komputer?... Benar-benar plugin terasa seperti bagian dari proyek.. . Memberikan plugin dari repositori git adalah omong kosong bagi saya, tetapi saya benar-benar berpikir bahwa saya tidak mengerti sesuatu tentang itu ...

@Ranoller idenya adalah untuk memindahkan plugin tersebut di luar proyek yang tidak perlu Anda ubah . Misalnya, InterpolatedCamera hanya akan menjadi simpul yang ingin Anda gunakan apa adanya, bukan mengubah kodenya.

Hal yang sama dapat terjadi dengan plugin khusus editor seperti daftar TODO atau integrasi git, dll. Itu adalah hal-hal yang ingin Anda gunakan tetapi tidak dapat diubah.

Ini sangat mirip dengan manajer paket dan perpustakaan bekerja di setiap bahasa yang bukan C dan C++. Anda memiliki file yang menentukan semua dependensi dan kemudian manajer paket akan mengambil dependensi tersebut. Ini terjadi bahkan ketika Anda mengganti PC - manajer paket akan mengunduh paket yang belum ada.

Ketika Anda ingin memodifikasi sesuatu, maka Anda membawa kode ke dalam proyek. Kemudian itu ada di git Anda dan proyek dengan semua kode sumbernya dll. Tapi itu tidak selalu terjadi.

Proposal saya adalah memiliki hal-hal di luar proyek secara default sampai Anda benar-benar perlu memodifikasi sesuatu.

Saat ini banyak aset sebagian besar adalah templat yang perlu Anda modifikasi, memiliki sistem seperti itu dapat berubah sehingga semuanya menjadi tujuan yang lebih umum melalui API, bukan melalui modifikasi sumber.

@karroffel Tapi bagaimana pewarisan lintas bahasa akan bekerja di setiap bahasa? Mungkin mudah untuk GDScript, yang digabungkan erat dengan mesin, tetapi ini adalah cerita yang sama sekali berbeda untuk bahasa tujuan umum seperti C# atau bahasa lain yang ditambahkan di atas GDNative.
Saya benar-benar tidak dapat melihat bagaimana ini dapat dicapai, apalagi bagaimana hal itu tidak dapat melakukan lebih banyak hal buruk daripada kebaikan.

IMO itu bukan ide yang baik untuk mengubah konten dari addon tergantung pada proyek Anda. Jika ada modifikasi yang diperlukan, cukup salin konten di luar folder addon dan lakukan perubahan di sana.

EDIT: atau "garpu" addon

@neikeq Apa yang Anda modifikasi ada di dalam proyek Anda. Saat Anda ingin memodifikasi addon, addon itu disalin di dalam proyek Anda dan hanya dimodifikasi secara lokal.

@karroffel Gagasan tentang plugin proyek dan plugin editor mungkin diperlukan untuk menghindari kebingungan, dengan pemisahan yang jelas dari keduanya.

@QbieShay Bagaimana jika ada pembaruan yang mengubah file yang Anda modifikasi?

@neikeq Warisan skrip bukan SOLUSI untuk masalah ini, itu hanya satu. Saat ini tidak ada cara yang baik untuk mengesampingkan fungsionalitas sebuah node dengan skrip yang dilampirkan ketika Anda ingin menggunakan bahasa pemrograman yang berbeda.

Jika kami memiliki opsi untuk mengganti metode di Script API maka itu juga bagus! (pada dasarnya mendefinisikan metode baru secara eksternal dan mengesampingkan metode yang ada).

@PLyczkowski itu saran yang akan berguna juga, tetapi apa yang saya usulkan tidak terbatas pada itu - dan karena suatu alasan.

Mari kita ambil contoh InterpolatedCamera lagi. Saya tidak akan pernah menyentuh kode sumbernya, saya hanya akan menggunakannya. Memiliki sumber dalam proyek saya akan sia-sia. Juga sebagian besar proyek yang saya buat semuanya 3D, jadi saya mungkin akan menyalin kode itu di semua proyek saya.

Di sisi lain, integrasi git mungkin sangat berguna untuk menambahkan perilaku kustom yang sulit diungkapkan dengan git hooks, jadi kustomisasi diperlukan.

Tidak ada garis hitam/putih ketika sesuatu harus berada di dalam proyek dan ketika di luar, editor atau tidak.

@neikeq

Bagaimana jika ada pembaruan yang mengubah file yang Anda modifikasi?

Dalam hal ini Anda akan kehilangan informasi versi, sehingga Anda tidak dapat memperbarui dengan mudah lagi. Anda harus menggunakan alat seperti git untuk kasus-kasus itu.

Idenya adalah

• di luar proyek: lebih mudah diperbarui, lebih mudah memiliki lintas proyek
• di dalam proyek: dapat disesuaikan, kehilangan status aset, tidak ada pembaruan otomatis

Pada dasarnya mereka menjadi file biasa setelah Anda menyalinnya ke proyek Anda.

Membaca ini, saya dapat mengatakan bahwa menghindari mengasapi dan meminimalkan ukuran file game adalah hal yang valid. Izinkan saya untuk memberikan beberapa ide di sini.

• Godot dapat menggunakan sistem yang menghapus kode permainan yang digunakan oleh node yang tidak digunakannya (mis. sebagian besar node 2D dengan banyak game 3D dan sebagian besar node 3D dengan banyak game 2D). Ini akan mengurangi tekanan untuk tidak menerima jenis node baru untuk menjaga ukuran file game tetap kecil. Pengguna Unity misalnya sudah menggunakan sesuatu yang mirip dengan hasil yang bagus.
• Godot mungkin memiliki browser aset bawaan yang terhubung ke halaman plugin di situs Godot. Anda memilih node kustom mana yang Anda inginkan dan itu akan menginstal secara otomatis ke lokasi yang benar. Plugin yang tidak digunakan dilucuti saat game dikemas.
• Bahkan mungkin, node kustom populer dapat digabungkan dengan build Godot (seperti yang dilakukan Blender dengan add-on). Node kustom juga harus ditandai karena biasanya levelnya lebih tinggi dan mungkin, sampai batas tertentu, lebih seperti kotak hitam daripada node yang lebih umum.

2 sen saya pula.

@Ace-Dragon

1. Saya pikir poin pertama Anda akan sangat keren untuk dimiliki sebagai fitur seluruh mesin. Jika Anda mengekspor game tidak menggunakan Node atau jika Node tidak digunakan oleh salah satu Node yang Anda gunakan dalam proyek Anda, akan lebih keren jika memungkinkan untuk secara otomatis mengecualikannya dari biner final. Di luar itu, saat ini Anda hanya perlu mengandalkan sakelar dan mengkompilasi ulang mesin. :-/

2. Ini pada dasarnya adalah apa yang sudah ada di Perpustakaan Aset. Masalahnya adalah ia tidak memiliki konsep dependensi, secara langsung memasukkan sesuatu ke direktori proyek Anda, dan tidak memiliki sarana apa pun untuk memelihara satu set plugin yang diberikan di seluruh sistem untuk setiap proyek yang Anda buat.

3. Node kustom selalu ditandai secara eksplisit, jadi tidak perlu khawatir tentang itu (mereka memiliki ikon skrip di sebelahnya karena Anda membuat node kustom menggunakan skrip untuk memperluasnya). Karena mereka adalah skrip, mereka tidak pernah dikirimkan bersama mesin. Mereka akan menjadi bagian dari semacam plugin, jadi jika ada, Anda mungkin memiliki sesuatu yang lebih seperti repo godot-next saya yang merupakan repositori "ekstensi simpul" untuk mengumpulkan barang-barang. Itu hanya akan menjadi kapasitas yang lebih "resmi" lebih dari apa pun (repo itu juga bisa menggunakan banyak pekerjaan, lol).

Ok, perlahan tapi tertangkap... Jika saya memelihara add-on di dalam proyek, saya bisa bekerja di kode plugin seperti di skrip lain tanpa kehilangan integrasi git dengan proyek saat ini dan tanpa kehilangan portabilitas... Tetapi jika saya ingin mengonversi salah satu plugin di alat untuk pengembang lain atau di alat umum untuk semua proyek saya, saya membagikannya dalam bentuk paket eksternal yang dapat diaktualisasikan dengan repositori git eksternal alat dan diubah ke orang lain dengan perpustakaan aset... Jika itu, bagi saya tidak apa-apa ... Jika pengembang lain menggunakan alat ini, dan membutuhkan versi pribadi mereka, dia perlu menyimpan di dalam proyek dan dalam hal ini plugin tidak aktual (jangan kehilangan pekerjaan mereka sendiri )... Dia?

@Ranoller Ya, saya pikir Anda sudah mendapatkan inti dari proposalnya.

Beberapa umpan balik tentang apa yang kalian diskusikan

1) Jika ini adalah masalah aktual yang perlu dipecahkan, saya lebih suka mendukung banyak skrip per node (yang hanya beberapa baris kode), daripada pewarisan lintas bahasa (yang gila). Saya masih tidak berpikir ini adalah masalah yang perlu dipecahkan.

2) Saya tidak menyukai gagasan tentang manajer paket dan pemasangan add-on di seluruh sistem. Saya pikir itu ide yang buruk dan tidak ada yang berarti sama sekali diperoleh dari ini. Saya telah melihat betapa traumatisnya bahkan bagi pengembang Unity untuk memperbarui versi aset dalam proyek besar dan melihat semuanya rusak dan menghabiskan waktu berhari-hari untuk memperbaikinya.

3) Saya tidak suka ide manajemen paket itu sendiri. Saya telah melihat pengguna Unity meretas apa yang mereka dapatkan dari toko aset hampir sepanjang waktu. Terlalu sering mereka hanya menggunakannya sebagai basis, kemudian mengerjakannya dan menyesuaikannya dengan kegunaan mereka sendiri, karena aset yang Anda dapatkan hanya 60/70% dari yang Anda inginkan.. atau mereka hanya ingin melihat bagaimana hal itu dilakukan dan kemudian melakukan hal mereka sendiri nanti.

Saya pikir tidak ada yang benar-benar diperoleh dalam kehidupan nyata dari proposal yang sedang dibahas, jadi saya sendiri tidak berencana untuk menambahkan banyak pada diskusi ini.

Berapa banyak ukuran mesin yang dapat kita kurangi jika kita mengizinkan orang mengekspor tanpa barang 3D dengan cara yang sederhana? Banyak permainan (setengah? lebih dari setengah?) tidak memerlukan fitur 3D tetapi mereka masih duduk di sana dalam biner yang sama. Saya tahu itu secara teoritis dapat dikompilasi ulang sendiri dengan makro di setiap platform, dengan sedikit investasi ...
Juga, mengikuti ide ini, jika modul hanyalah perpustakaan dinamis "internal" yang merupakan bagian dari distrib mesin resmi, menambahkan lebih banyak fitur ke mesin tidak akan menjadi masalah dalam arti bahwa mereka dapat disingkirkan dengan sangat mudah (hanya saja ), namun menggunakan pustaka dinamis seperti ini bisa sedikit membatasi untuk beberapa platform (terutama ponsel dan HTML5). Jadi untuk modul saya akan mengerti bahwa GDNative lebih disukai (oh tunggu... memiliki masalah yang sama^^).

@reduz bagaimana beberapa skrip bekerja? Dan bagaimana kontribusinya pada ekstensi mesin? Apakah Anda menjelaskan ide Anda dalam masalah yang ada? (bertanya karena mungkin terlalu banyak untuk menjelaskannya di utas ini)

tambahkan manajemen ketergantungan yang tepat dengan pemasangan aset di seluruh sistem. Pindahkan add-on dari proyek itu sendiri dengan cara mengembalikannya untuk dimodifikasi

Tidak. Saya ingin mereka di direktori proyek demi ketahanan. Tapi mungkin dengan cara memperbarui yang dipilih secara manual dengan manajer paket, dan mungkin dengan caching di seluruh sistem.

Adapun masalah mengasapi, saya akan menghargai lebih banyak kontrol atas _modules_ sebagai gantinya, dan ini sudah dipilih pada jajak pendapat Patreon Januari 2018:

Prioritas Peta Jalan: Lebih banyak opsi untuk memilih keluar dari kompilasi bagian mesin untuk membuat ukuran biner yang lebih kecil [ Diharapkan untuk 3.1 ]

Sulit untuk mengomentari proposal ini karena menyentuh berbagai hal dan orang-orang mengomentari aspek yang berbeda dan mengangkat isu yang berbeda.

Secara keseluruhan saya pikir proposal untuk "manajer dependensi" terdengar bagus di atas kertas, tetapi saya pikir implementasinya tidak akan memberikan manfaat apa pun yang tidak akan dihasilkan oleh vendor tambahan di folder proyek. Ini akan membutuhkan penggabungan mekanisme kompleks untuk manajemen ketergantungan untuk menyelesaikan 1 kasus "lebih mudah dipasang". Proyek ini sudah memiliki 3000+ masalah terbuka dengan tim kecil kontributor. Memperkenalkan sesuatu yang kompleks seperti manajemen ketergantungan adalah pijakan menurut saya.

Saya setuju dengan @reduz bahwa intinya harus minimalis. Menurut pendapat saya, segala sesuatu yang tidak dapat diklasifikasikan sebagai "inti" harus dimasukkan secara independen. Sebagai pengguna, saya berharap Godot menjadi _engine_ game multi-platform. Jika saya menginginkan _game framework_ godot (kendaraan, kamera interpolasi, medan, pengontrol pemutar, dll.) itu harus tersedia sebagai add-on (atau modul?) kelas satu yang independen dari inti. Saya pikir meningkatkan cerita addon membantu dalam hal ini, tetapi manajer ketergantungan penuh dan manajer addon otomatis tampaknya mendorongnya untuk keuntungan bersih yang rendah.

Komentar terakhir saya adalah berhati-hati dalam melayani "pemula" dan mengabaikan pengguna "berkuasa". Godot telah mendapatkan perhatian dari pengguna yang lebih mahir karena fitur-fiturnya yang canggih (modul, gdnative, gdscript, editor, dll.) dan fleksibilitas. Pengguna seperti inilah yang menguji godot, mendorong batasannya, menjelajahi apinya, dan sering kali berkontribusi kembali ke proyek. Ini adalah pengguna yang sama yang dapat membuat symlink ke direktori di sistem file mereka untuk menggunakan kembali add-on mereka di beberapa proyek.

Jika idenya adalah untuk menghapus node tingkat yang lebih tinggi dari inti, maka node tersebut harus sudah tersedia dan mudah ditemukan untuk diunduh. Idealnya kami dapat mempertahankannya sebagai "resmi", sehingga mereka memiliki visibilitas yang lebih baik (seperti yang dimiliki node dalam mesin). Kemudian aset resmi dapat digunakan dalam demo dan tutorial tanpa banyak masalah.

Keuntungan dari outsourcing adalah bahwa mereka dapat ditingkatkan dan dirilis tanpa harus menunggu versi mesin baru. Jadi bug dapat segera diperbaiki, karena untuk ekstensi cukup sederhana untuk mengemas rilis baru.

Saya kira pada akhirnya manajemen paket akan cukup merepotkan sebagian besar waktu. Bahkan dalam kasus versi baru dari simpul khusus yang Anda tambahkan ke proyek Anda, memperbaruinya dapat menyebabkan banyak masalah lain (bahkan dengan semver, karena Anda mungkin telah mengatasi bug yang sekarang telah diperbaiki).

OTOH untuk beberapa plugin editor mungkin masuk akal untuk keluar dari proyek dan sering memperbaruinya. Plugin importir Tiled saya adalah contohnya. Anda kemungkinan besar tidak ingin itu dikirimkan bersama permainan dan ingin memiliki versi terbaru yang mendukung lebih banyak fitur dan memiliki perbaikan bug.

Ini bahkan lebih berlaku untuk ekstensi editor lainnya, seperti pengelola git dan pelacak waktu. Anda bahkan mungkin tidak peduli jika rekan tim Anda memiliki plugin pelacak waktu atau tidak, itu tidak terkait dengan proyek. Namun, Anda harus memasukkan folder addons Anda dan mengaktifkannya di pengaturan proyek, lalu berhati-hatilah untuk tidak mengkomitnya dengan sisa permainan. Itu mungkin plugin minoritas, tetapi masih memiliki plugin di seluruh sistem yang tidak terikat dengan proyek memiliki kasus penggunaan nyata.

Saya percaya jalan tengahnya adalah membuat manajer paket sebagai alat eksternal, tidak terintegrasi di Godot. Bahkan tidak perlu resmi (walaupun bisa "didukung"). Jika beberapa perubahan diperlukan di mesin dasar untuk mendukung ini (seperti memiliki plugin global), maka tidak akan menjadi masalah untuk menambahkannya, terutama jika hanya editor.

Kemudian mereka yang menganggapnya bermanfaat dapat menggunakannya. Jika itu tersebar luas dan semua orang menggunakannya, kami akan memiliki statistik penggunaan dan umpan balik tentang kegunaan untuk memutuskan apakah dan bagaimana mengintegrasikannya sepenuhnya di mesin dasar.

Sekarang, warisan lintas-skrip bagi saya adalah tidak-tidak (jika itu mungkin). Multiscript agak aneh, tetapi secara efektif akan menggantikan pewarisan lintas skrip dengan cara yang lebih bersih. Meskipun menimbulkan beberapa kekhawatiran, seperti: bagaimana cara memanggil fungsi skrip lain di objek yang sama? Saya kira itu diskusi lain.

Merujuk skrip dengan nama OTOH terdengar sangat bagus. Idealnya, semua sumber daya dapat direferensikan dengan nama sehingga jalur tidak menjadi masalah untuk dipecahkan jika Anda memutuskan untuk memindahkan sesuatu.

@vnen satu-satunya masalah yang masih saya lihat adalah ketidakcocokan antara add-on dan proyek. Bagaimana Anda akan mengatasi masalah itu?
Karena jika ada lib ekstensi resmi yang dikelola oleh Godot, baik setiap node dikirimkan dalam setiap bahasa yang memungkinkan, atau saya melihat pewarisan lintas bahasa satu-satunya cara agar kami dapat menjaga keramahan pengguna.

@vnen jika Anda mereferensikan semua aset dengan nama maka itu akan menjadi kekacauan yang saling bertentangan. Itu lebih cocok untuk skrip karena hanya programmer yang harus membuat nama unik untuk kelas mereka untuk mengetik dan menggunakannya (atau lebih jarang, sumber daya). Untuk hal-hal lain, jika kita menghilangkan jalur, itu akan membutuhkan ini https://github.com/godotengine/godot/issues/15673 , kecuali jika Anda juga ingin artis, desainer, dll. harus memberi nama semua aset mereka secara unik (yang masih datang dengan masalah penggantian nama).

@Zylann @vnen TypeDB yang saya tulis harus memungkinkan orang untuk secara opsional mendaftarkan nama untuk aset apa pun, secara teoritis. Saat ini saya hanya menggunakannya untuk skrip, dan berencana untuk juga melakukannya untuk jenis adegan khusus, tetapi Anda juga dapat memodifikasinya agar berfungsi dengan sumber daya. Logika saat ini hanya memiliki HashMap masing-masing untuk skrip dan adegan, tapi mungkin saya bisa menggeneralisasi logika untuk menangani segala jenis aset, semuanya dalam HashMaps yang dikategorikan.

Saya dapat menghormati kekhawatiran reduz dengan hal-hal di seluruh sistem, dan itu tentu saja kekhawatiran dengan plugin yang akan memodifikasi penawaran mesin, tetapi ketika datang ke fitur untuk Editor secara khusus, seperti yang dijelaskan vnen, saya pasti dapat melihat itu berguna dalam cara yang relatif aman. Jika orang menambahkan plugin untuk memberi Editor lebih banyak fitur, itu bukan hal yang biasanya akan mereka buka dan modifikasi sendiri. Mereka hanya akan menggunakannya apa adanya, atau jika mereka melakukan modifikasi, mungkin untuk melakukan PR perubahan tersebut guna meningkatkan alat. Anda sama sekali tidak mengadaptasinya ke permainan. Dengan demikian, jika untuk plugin seperti ini, saya pikir kita harus memiliki cara untuk memberikan fitur tersebut dengan mudah ke mesin ketika Anda memulai proyek baru (entah bagaimana).

Salah satu metode yang memungkinkan yang dapat membuat segalanya lebih mudah tanpa memerlukan manajer ketergantungan adalah dengan tidak membagikan dependensi antar plugin dan sebaliknya menduplikasinya di dalam proyek, dengan cara itu pembuatan versi tidak menjadi masalah. Itu akan membuat proyek individu lebih besar secara potensial, tetapi jika itu untuk konten yang relevan dengan permainan dan orang-orang akan mengotak-atik semuanya, seperti yang dikatakan reduz, maka mereka dapat memindahkan dependensi. Apa yang kita perlukan dalam kasus itu adalah cara plugin untuk mendeklarasikan APA dependensi eksternal-plugin yang mereka miliki dan memberi pengguna opsi untuk menyesuaikan di mana mereka mencari plugin dependen itu. Dengan begitu, jika mereka memilih untuk memindahkan plugin dan meminta plugin lain mencarinya di lokasi yang sama, mereka dapat menyesuaikannya. Tapi kemudian, secara default, semuanya akan bekerja di luar kotak dengan mengelola dependensinya sendiri. Kasus ini mungkin juga akan lebih mudah ditangani dengan seluruh proposal plugin-sebagai-sub-proyek (#19178).

Ini akan mencegah kita dari memiliki dependensi global yang memerlukan manajer dependensi sama sekali (masalah reduz nomor 3). Dan kami dapat menggabungkannya dengan fitur yang memungkinkan pengguna membuat daftar aset favorit dari Pustaka Aset yang dapat mereka pilih untuk dipasang secara otomatis ke dalam proyek mereka saat proyek baru dibuat (jadi semuanya masih disimpan secara lokal, tetapi itu terjadi secara otomatis dan mereka tidak perlu keluar secara manual, temukan semua plugin pilihan mereka dan unduh dan instal secara manual). Ini akan memperbaiki masalah kegunaan yang ingin ditangani oleh @karroffel sehubungan dengan memperluas mesin dengan aset identik dengan mudah saat membuat proyek baru.

Untuk lebih banyak plugin khusus editor yang tidak perlu diduplikasi, mungkin orang bisa menandai plugin "favorit" itu dan mereka akan membuat symlink untuk mereka secara otomatis, menyimpan plugin di folder pengguna. Jadi, mungkin memiliki "Favorit Editor" dan "Favorit Proyek" untuk "Saya ingin ini di setiap proyek, simpan di lokasi bersama dan buat symlink" dan "Saya ingin ini di setiap proyek, duplikat", masing-masing.

Gabungkan itu dengan hal-hal TypeDB untuk menamai skrip/menyesuaikan tipe khusus, dan saya yakin itu akan mengatasi semua masalah yang disebutkan dengan benar kecuali untuk masalah warisan skrip/multiskrip lintas bahasa yang sama sekali berbeda.

Jadi, mungkin memiliki "Favorit Editor" dan "Favorit Proyek" untuk "Saya ingin ini di setiap proyek, simpan di lokasi bersama dan buat symlink" dan "Saya ingin ini di setiap proyek, duplikat", masing-masing.

Mungkin lebih nyaman untuk memiliki "bundel" plugin - buatan pengguna yang disetujui secara resmi + lokal yang dibuat pengguna. Jadi, alih-alih "Favorit Editor" dan "Favorit Proyek", kami memiliki "Penembak Orang Pertama", "Game Blok Voxel", atau hanya "Barang saya". Hampir mirip seperti aset starter Unity, tetapi tidak perlu mengasapinya dengan tekstur dll, berbagai jenis wajah maskot Godot sudah cukup :D

Ini juga berfungsi sebagai manajer paket, di mana manajer paket sekarang adalah bundel plugin kurasi manusia.

@starry-abyss Plugin yang dibuat orang sekarang sudah berpotensi menjadi "bundel" plugin lain (pengguna atau pengembang plugin bisa memindahkannya sendiri dan menggabungkannya). Tujuannya di sini adalah untuk memiliki perbedaan fungsional antara kategori di mana editor benar-benar melakukan operasi peningkatan kegunaan atas nama pengguna sehingga pengguna tidak perlu melakukan sesuatu secara manual.

Sejauh ini, kami sudah memiliki fitur "bundel plugin kurasi manusia". Masalahnya adalah dengan mengotomatisasi tugas-tugas yang membosankan sambil tetap dapat disesuaikan dengan produktivitas yang efisien dalam semua kasus penggunaan.

@Zylann

jika Anda merujuk semua aset dengan nama maka itu akan menjadi kekacauan yang saling bertentangan. Itu lebih cocok untuk skrip karena hanya programmer yang harus membuat nama unik untuk kelas mereka untuk mengetik dan menggunakannya (atau lebih jarang, sumber daya).

Apakah ini masalah besar untuk hal-hal namespace yang benar? Tapi bisa jadi UID, itu tidak masalah bagi saya selama itu tidak bergantung pada jalur. Bahkan jalurnya seperti sebuah nama, karena sumber daya dipetakan ulang ke rekanan yang diimpor...

@QbieShay

satu-satunya masalah yang masih saya lihat adalah ketidakcocokan antara add-on dan proyek. Bagaimana Anda akan mengatasi masalah itu?

Jika ini benar-benar masalah, maka multi-skrip kemungkinan merupakan solusi paling sederhana. Itu dihapus sebagian besar karena diskusi di #8546, tapi saya pikir ini bisa diselesaikan tanpa banyak usaha.

Saya percaya bahwa masalah beberapa plugin melakukan hal yang sama adalah virtual. Kami sudah memiliki sistem bintang di asetlib, sistem ini hanya ini, indikator apa yang umum digunakan dan disukai.

Hal yang diabaikan tetapi menurut saya adalah salah satu alasan orang meminta tambahan di mesin inti adalah ini: Siapa yang akan mengkompilasi hal ini untuk semua platform?

Tentu saja untuk plugin gdscript ini bukan masalah, tapi untuk plugin Cpp ini masalah besar.

Jika kita tidak menyelesaikan masalah ini maka diskusi tentang apa yang akan ada di dalam mesin inti akan berubah menjadi, plugin mana yang akan ditandai sebagai resmi, dan dengan menandai plugin sebagai resmi akan merusak sistem bintang, menyebabkan orang pergi untuk hanya membintangi sebuah plugin karena itu hanya yang resmi.

Jadi menurut saya kita harus menyelesaikan masalah ini terlebih dahulu, dan saya tidak tahu bagaimana caranya. Apakah mungkin misalnya untuk mengkompilasi untuk semua platform melalui Linux? Jika demikian maka kita dapat menggunakan sesuatu seperti Ubuntu Imager : https://www.maketecheasier.com/create-linux-distro/ untuk membuat lingkungan linux yang sudah diatur untuk pembuat plugin dan pengguna GDNative.

Apakah mungkin misalnya untuk mengkompilasi untuk semua platform melalui Linux? Jika demikian maka kita dapat menggunakan sesuatu seperti Ubuntu Imager : https://www.maketecheasier.com/create-linux-distro/ untuk membuat lingkungan linux yang sudah diatur untuk pembuat plugin dan pengguna GDNative.

Tidak (build macOS dan iOS hanya dapat benar-benar dikompilasi dari macOS), dan menurut saya, memaksa orang untuk mem-boot OS Linux langsung agar dapat mengunggah pustaka GDNative ke pustaka aset adalah ide yang bagus.

Namun, dimungkinkan untuk mengompilasi untuk semua platform menggunakan Travis CI dan AppVeyor, yang dapat Anda atur secara gratis di repositori GitHub publik.

Jika kita tidak menyelesaikan masalah ini maka diskusi tentang apa yang akan ada di dalam mesin inti akan berubah menjadi, plugin mana yang akan ditandai sebagai resmi, dan dengan menandai plugin sebagai resmi akan merusak sistem bintang, menyebabkan orang pergi untuk hanya membintangi sebuah plugin karena itu hanya yang resmi.

Nah, sistem bintang tidak pernah diterapkan, jadi Anda tidak bisa menilai apa pun. Untuk plugin resmi, bukan berarti kami akan memilih satu dan menandainya sebagai resmi, kamilah yang membuat dan memeliharanya.

Node bawaan untuk hal-hal dasar adalah salah satu hal terbaik dari editor, jika node atau sumber daya penting akan dihapus, Manajer Proyek akan memerlukan template untuk mengunduh node umum secara otomatis.

Proposal ini juga memiliki risiko untuk menghidupkan mesin "selalu online" dan "toko sampah" lain, jika dilakukan, banyak hal lain yang perlu mendapatkan dukungan resmi (perbaikan bug) dan ketersediaan (pembaruan versi).

Dan toko harus menawarkan bundel resmi untuk penggunaan offline (dengan dukungan toko offline di editor).

jika selesai, banyak hal lain yang perlu mendapatkan dukungan resmi (perbaikan bug) dan ketersediaan (pembaruan versi).

TBH, merawat barang-barang di mesin atau di toko hampir sama. Node kendaraan, misalnya, memiliki sedikit laporan bug karena hampir tidak ada yang menggunakannya, dan bahkan bug yang dilaporkan tidak pernah diperbaiki. Saya menemukan outsourcing node semacam itu jauh lebih baik karena lebih mudah untuk membuat orang mencoba memperbaiki sesuatu tanpa harus mengacaukan sumber mesin, jadi ada lebih banyak kontributor potensial.

Jika node mesin memiliki masalah, orang akan membuka laporan bug. Tetapi jika itu adalah plugin dengan kode GDScript, cukup mudah bagi orang tersebut untuk mengubah kode dan mengujinya, kemungkinan berkontribusi perbaikan kembali ke komunitas. Saya benar-benar melihat ini sebagai keuntungan. Tetapi hanya jika node eksternal tersebut dapat memiliki integrasi yang mudah, yang tidak terjadi saat ini. Itu termasuk visibilitas yang baik dan dokumentasi terintegrasi.

Dan toko harus menawarkan bundel resmi untuk penggunaan offline (dengan dukungan toko offline di editor).

Ya, dan menginstal paket offline juga seharusnya mudah.

@reduz

Saya tidak menyukai gagasan tentang manajer paket dan pemasangan add-on di seluruh sistem. Saya pikir itu ide yang buruk dan tidak ada yang berarti sama sekali diperoleh dari ini. Saya telah melihat betapa traumatisnya bahkan bagi pengembang Unity untuk memperbarui versi aset dalam proyek besar dan melihat semuanya rusak dan menghabiskan waktu berhari-hari untuk memperbaikinya.

Oke, tapi kenapa ? Apa batasan dan masalah aktual yang Anda lihat darinya? Mengatakan "Saya tidak menyukainya" tanpa mengatakan mengapa tidak akan meyakinkan orang bahwa itu bukan ide yang baik; Anda harus memberikan setidaknya beberapa penjelasan selain alasan samar yang disebutkan.

Oke, tapi kenapa? Apa batasan dan masalah aktual yang Anda lihat darinya? Mengatakan "Saya tidak menyukainya" tanpa mengatakan mengapa tidak akan meyakinkan orang bahwa itu bukan ide yang baik; Anda harus memberikan setidaknya beberapa penjelasan selain alasan samar yang disebutkan.

Dengan asumsi registri "addon" global pada sistem:

• Unduh addon v1.3 dari sistem add-on online. Addon diinstal ke ~/.godot atau yang tidak
• Versi dikaitkan dengan proyek saya di ~/my-project di beberapa jenis toko lokal (file, sqlite, dll.)
• Saya meningkatkan ke v1.4. Sekarang manajer addon saya harus tahu bahwa 1.3 tidak digunakan oleh proyek apa pun dan bersihkan. Jadi manajer memiliki fungsionalitas ekstra untuk melacak dependensi dan proyek apa yang memiliki dependensi apa. Atau tidak ada yang menambahkan fungsi ini sehingga mesin lokal saya tercemar dengan beberapa versi addon yang sama
• Saya memutuskan saya ingin memindahkan proyek saya ke ~/big-project/game . Sekarang saya memerlukan cara untuk memperbarui referensi ke proyek saya di registri addon. Bagaimana aku melakukan itu? Apakah saya harus menjalankan addon manager secara terpisah? Manager register new_proj_location ?
• Keputusan sekarang dibuat untuk menyimpan dependensi secara lokal ala requirements.txt python style. Bagus, masalah terpecahkan. Kecuali saya kembali tidak mengetahui proyek mana yang bergantung pada paket global apa, saya harus memindai sistem untuk proyek godot atau mendaftarkan setiap proyek untuk menghindari menumpuknya versi.
• Baik, saya hanya mengatasi masalah ini. Bersihkan paket mati secara manual dari waktu ke waktu. Jadi saya sedang mengerjakan VehicleBodyAddon untuk proyek saya menggunakan v1.5. Ugh, Itu F * M untuk perhitungan Akselerasi tetapi saya ingin melakukan F * M * 5. Biarkan saya dengan cepat memodifikasi kodenya ... Ups, ada semua proyek saya yang lain yang menjalankan addon itu.
• Biarkan saya membuat addon baru yang bergantung pada addon lainnya. Hmmm sekarang saya harus mendaftar bahwa addon kustom baru saya tergantung pada yang sudah ada. Sekarang saya perlu memperluas manajer untuk tidak hanya mengunduh add-on dari lokasi yang jauh tetapi juga untuk bekerja dengan jalur lokal atau repositori git atau sesuatu.

Dengan asumsi add-on "vendored':

• Unduh addon ke direktori addon
• Memperbarui menimpa addon di direktori

Jadi manajer memiliki fungsionalitas ekstra untuk melacak dependensi dan proyek apa yang memiliki dependensi apa. Atau tidak ada yang menambahkan fungsi ini sehingga mesin lokal saya tercemar dengan beberapa versi addon yang sama

Ini persis seperti yang dilakukan perintah gem Ruby lainnya, dan tidak ada yang mengeluh di sana karena mereka memiliki perintah untuk membersihkan permata versi lama (istilah Ruby untuk add-on) yang tidak memiliki permata lain bergantung padanya. Plus, mengapa kita perlu mempertahankan versi lama ketika, jika kita memperbarui, versi baru mungkin sebagian besar kompatibel? Dorong datang untuk mendorong, pengguna bisa mendapatkan versi lama lagi jika program mereka benar- benar tergantung pada versi lama, yang kemungkinan besar tidak akan.

Saya memutuskan saya ingin memindahkan proyek saya ke ~/big-project/game . Sekarang saya memerlukan cara untuk memperbarui referensi ke proyek saya di registri addon.

Anda tidak, sungguh. Anda berpikir terlalu dalam tentang hal ini ketika manajer pengaya bisa saja... menggunakan daftar proyek dari manajer proyek, dan mengabaikan jalur apa pun yang tidak ada. Tentu saja, itu hanya jika itu benar- benar perlu untuk melacak proyek dan persyaratannya, yang menurut saya tidak perlu ketika kita bisa menyimpan versi terbaru dari pengaya apa pun yang telah kita unduh seperti pengaya lainnya. manajer di luar sana.

Keputusan sekarang dibuat untuk menyimpan dependensi secara lokal ala requirements.txt python style. Bagus, masalah terpecahkan. Kecuali saya kembali tidak mengetahui proyek mana yang bergantung pada paket global apa, saya harus memindai sistem untuk proyek godot atau mendaftarkan setiap proyek untuk menghindari menumpuknya versi.

Persyaratan gaya Python.txt akan menjadi pilihan yang bagus untuk sistem pengaya semacam ini. Dengan begitu jika proyek benar-benar membutuhkan beberapa versi lama (tetapi sekali lagi, Anda akan sering menginginkan versi terbaru), kami dapat menentukannya, dan jika pengelola add-on akhirnya menghapus versi lama itu, ia dapat mengetahui untuk mengunduh ulang nanti.

Jadi saya sedang mengerjakan VehicleBodyAddon untuk proyek saya menggunakan v1.5. Ugh, Itu F * M untuk perhitungan Akselerasi tetapi saya ingin melakukan F * M * 5. Biarkan saya dengan cepat memodifikasi kodenya ... Ups, ada semua proyek saya yang lain yang menjalankan addon itu.

Atau gunakan salinan add-on lokal untuk proyek itu? Jika itu benar-benar memerlukan perubahan yang hanya berlaku untuk satu proyek, dan Anda benar-benar tidak ingin membuat salinan lokal untuk proyek tersebut, buat saja file .gd yang memperluasnya dan buat perubahannya, lalu gunakan file GD baru itu sebagai pengganti file dari addon.

Biarkan saya membuat addon baru yang bergantung pada addon lainnya. Hmmm sekarang saya harus mendaftar bahwa addon kustom baru saya tergantung pada yang sudah ada. Sekarang saya perlu memperluas manajer untuk tidak hanya mengunduh add-on dari lokasi yang jauh tetapi juga untuk bekerja dengan jalur lokal atau repositori git atau sesuatu.

Sub-modul Git. Persyaratan lain.txt (seperti yang dilakukan python). Atau cukup beri tahu pengguna bahwa itu memerlukan Add-on X. Ini tidak sesulit yang Anda bayangkan. Sebagian besar pengguna Godot tidak bodoh. Mereka tahu apa artinya "Pengaya ini membutuhkan: Add-on X Core, Add-on Y, Add-on Z".

@rminderhoud Jika rekomendasi Anda adalah untuk menyimpan salinan add-on proyek di setiap proyek sesuai kebutuhan (sehingga hanya memiliki versi yang dibutuhkan dan bebas untuk memodifikasinya tanpa menyebabkan masalah), maka mungkin saran saya sebelumnya dapat menangani inti masalah seputar Masalah ini? Yaitu, buat utilitas di dalam EditorSettings yang memungkinkan pengguna untuk menentukan add-on apa yang ingin mereka instal secara otomatis saat mereka membuat proyek baru.

Kami bahkan dapat membuat utilitas serupa yang memungkinkan orang membentuk tautan keras ke lokasi pengguna:// untuk menyimpan yang tertentu (terutama untuk add-on yang menambahkan fitur editor). Jika pengguna memilih untuk melakukan itu secara tidak bertanggung jawab dan mengacaukan proyek mereka, itu akan menjadi keputusan mereka sendiri. Metode default hanya menyalin semua aset selama pembuatan proyek bisa sangat berguna.

Menambahkan sistem plugin baru tidak boleh tidak kompatibel dengan res://addons seperti sekarang... Dan ini karena:

Sistem yang sebenarnya sangat bagus...

Saya ulangi:

Sistem yang sebenarnya sangat bagus...

Tidak ada keluhan sebelumnya tentang hal itu.

Saya terlambat untuk diskusi ini, berikut beberapa pemikiran tentang proposal:

• Saya pribadi belum menggunakan banyak 'aset' dan merasa folder addon apa adanya mudah digunakan.
• Saya mengerti apa yang akan dilakukan pewarisan skrip lintas bahasa dan masalah apa yang akan diselesaikannya (izinkan pengembang C # untuk memperluas dari skrip GDScript untuk menambahkan fungsionalitas khusus menggunakan C #) (bukan karena saya memiliki keinginan untuk menggunakannya) tetapi saya tidak yakin apa yang akan dilakukan beberapa skrip per node. Oh, jadi alih-alih skrip C# yang memanjang dari skrip GDScript, itu akan dapat memanggilnya? Skrip mana yang akan menjadi yang utama? Bagaimana kode C# mengubah apa yang dilakukan skrip GDScript?
• Mengizinkan skrip direferensikan oleh nama kelas/ruang nama (TypeDB) mungkin berguna. Saya baik-baik saja dengan res://paths , tetapi memang benar bahwa mewarisi dari sesuatu di addons menghasilkan nama jalur yang sangat panjang. Bukan masalah besar, tetapi bagus untuk dimiliki - mungkin diperlukan (atau lebih disukai) meskipun untuk pewarisan lintas bahasa.

Desain yang lebih sederhana untuk manajemen aset yang saya sarankan adalah

• Memiliki dependensi.json (atau hanya menyimpan data ke pengaturan proyek) berguna, supaya saya tahu versi aset mana yang saya unduh dan apakah ada versi yang diperbarui. Saya rasa itu perlu info.
• Tidak, jangan biarkan aset dapat mendefinisikan dependensi. Saya tidak berpikir aset Godot akan memiliki ketergantungan yang tinggi satu sama lain seperti yang dimiliki modul npm. Biarkan pengembang aset menyatakan dalam dokumentasi jika itu benar-benar bergantung pada aset lain dan biarkan pengguna menginstal secara manual. Ini akan menyederhanakan banyak hal dan kita tidak perlu membuat hal validasi ketergantungan lain yaitu kode mengasapi / lebih banyak kode untuk dipelihara.
• Tidak, jangan simpan aset di lokasi 'global'. Menyimpannya di folder addons proyek sudah bagus. Ini memungkinkan mereka berkomitmen dengan kontrol sumber dengan proyek dan membuatnya mudah untuk dikelola. Bahkan npm node_modules menyimpan modul proyek di dalam proyek.
• Sekarang, perbaiki browser aset sehingga dapat mencantumkan aset terinstal mana yang telah diperbarui dan Anda dapat memperbaruinya jika diinginkan.
• Sekarang, masuk akal untuk dapat memiliki add-on 'global' untuk add-on yang hanya merupakan peningkatan editor. Jadi addons normal masih masuk ke folder addons proyek, tetapi untuk add-on terkait editor, Anda memiliki opsi untuk menginstalnya secara global. Ini juga memindahkan kode itu ke luar folder addons proyek sehingga tidak masuk ke paket rilis. (Ini mirip dengan npm install -g untuk alat pengembangan)

Jadi hanya beberapa perbaikan untuk membantu melacak aset yang diperbarui dan dapat menginstal add-on editor secara global.

Dengan asumsi bahwa kami tidak menangani dependensi, saya merasa mungkin ada masalah kemampuan untuk ditemukan/kemudahan penggunaan bagi pengguna. Katakanlah pengguna baru ingin mencoba plugin atau "paket aset" yang memiliki ketergantungan. Paket ditampilkan di aset lib, mengunduhnya, lalu gagal berfungsi, kemungkinan dengan beberapa "skrip internal gagal memuat" atau sesuatu seperti itu. Itu samar.

• Setiap pengembang yang berani memiliki setidaknya satu dependensi harus menyiapkan kode boilerplate untuk menunjukkan kepada pengguna bahwa mereka perlu menginstal dependensi (bahkan jika paket tersebut hanya demo untuk plugin itu!)
• Atau setidaknya asetlib menunjukkan itu?

Juga memberi +1 untuk memperbarui aset dengan mudah, tidak perlu menelusurinya lagi di perpustakaan.

Memang benar, namun begitu pengguna melihatnya tidak berfungsi, mereka akan segera mencari dokumentasi dan melihat bahwa mereka perlu menginstal aset lainnya.

Pada titik ini hanya masalah yang dibayangkan. Dan dalam pola pikir pengelola proyek yang saya lihat, masuk akal untuk tidak menerapkannya sampai kami mengetahui bahwa itu benar-benar masalah. Yaitu. ada banyak aset yang memiliki ketergantungan pada aset lain dan pengguna mengalami banyak masalah dengannya.

Sebagai solusi yang direkayasa dengan baik, saya setuju bahwa akan baik untuk memiliki dan dapat mendorong pengembangan ekosistem aset yang dibangun di atas / tergantung pada aset lain.

Tambahkan dependensi teratas antara aset karena pembaruan (yang umum di mesin yang bergantung pada aset pihak ketiga), banyak versi plugin yang sama harus disimpan di perpustakaan.

@eon-s Jadi, kira-kira seperti saran @bojidar-bg ?

Saya pikir masalah yang lebih penting yang dibahas di sini adalah tentang topik memasukkan hal-hal dalam mesin inti vs menjadikannya sebagai ekstensi atau ekstensi resmi.

Saya pribadi sangat menyukai gagasan untuk dapat menyesuaikan mesin dan menghapus semua yang sebenarnya tidak saya gunakan. [Dapatkah seseorang menunjukkan kepada saya bagaimana saya akan menghapus semua barang 3D misalnya? Dan bisakah saya menonaktifkan kompilasi modul yang tidak saya gunakan? Bagaimana?]

Masalahnya, ketika seseorang mengusulkan jenis simpul baru, mis. Spring Arm yang disebutkan atau kelas baru misalnya. kelas RNG yang lebih baik, atau jika beberapa node inti yang ada akan dihapus misalnya. Pengendali Kendaraan ... itu adalah kode C++. Jika mereka tidak termasuk dalam inti, lalu bagaimana mereka akan ditambahkan sebagai ekstensi? Aset asli GDN? Itu akan menjadi banyak dll dan perpustakaan bersama untuk dikelola/dibangun.

Sebagai seseorang yang membangun godot build saya sendiri, saya sebenarnya lebih suka memiliki cara untuk menginstalnya ke folder godot build saya. Misalnya, jika itu adalah modul, saya hanya akan mengkloningnya ke folder modul saya, atau mungkin akan ada alat yang mengotomatiskannya. Anda akan dapat memilih semua modul yang ingin Anda gunakan dari daftar modul resmi, modul ekstensi resmi, dan juga dari yang dikirimkan pengguna. Kemudian unduh (git clone) mereka, dan kemudian Anda dapat melanjutkan dan membangun Godot kustom Anda. Juga akan dapat melihat mana yang telah diperbarui dan memperbaruinya dan menginstal yang baru nanti. (Ini mengacu pada kode C++.)

Jadi, saya rasa pertama-tama kita membutuhkan pustaka aset yang lebih baik dan fleksibel (instalasi aset, dependensi, pembuatan versi, dll.) dan integrasi/ekstensi plugin yang lebih mudah (alat editor, node kustom yang dapat skrip, dll.) sebelum mencoba menghapus fitur dari mesin .

Menanggapi @chanon di sini.

Tidak, jangan biarkan aset dapat mendefinisikan dependensi. Saya tidak berpikir aset Godot akan memiliki ketergantungan yang tinggi satu sama lain seperti yang dimiliki modul npm.

Tapi kenapa? Pada saat itu, mengapa tidak membiarkan aset memiliki file dependensi ini karena tidak akan membahayakan apa pun? Alasan mengapa banyak modul npm memiliki dependensi adalah karena hal itu menyelamatkan semua orang dari kerumitan dan menggunakan kembali kode dari modul lain yang bahkan mungkin sudah diinstal oleh pengguna. Hal yang sama berlaku untuk permata Ruby, Python melalui pip , bahkan manajer paket di distro Linux mengizinkannya. Saya tidak mengerti mengapa kita tidak boleh mengizinkan dependensi pada aset hanya karena mereka mungkin tidak sering digunakan.

Memang benar, namun begitu pengguna melihatnya tidak berfungsi, mereka akan segera mencari dokumentasi dan melihat bahwa mereka perlu menginstal aset lainnya.

Saya tidak setuju dengan sentimen ini. Akan ada banyak orang yang akan mencari dokumentasi terlebih dahulu, tentu saja, tapi saya cukup yakin bahkan mereka akan menjadi kesal karena harus mencari setiap aset yang dibutuhkan setiap saat di pustaka aset. Tapi saya pikir perlu juga disebutkan bahwa selalu ada sekelompok orang yang sepertinya tidak pernah mencari masalah di Google sebelumnya, dan hanya akan mengeluh kepada penulis aset bahwa aset mereka tidak berfungsi.

Saya bahkan tidak setuju dengan ide menghapus fitur hanya karena bisa dilakukan di GDScript. Sederhananya, itu bertentangan dengan tujuan Godot dari " node untuk semua kebutuhan Anda " jika Anda akan memaksa sebagian besar pengguna untuk mengunduh atau mengimplementasikan alat/fitur/dll yang mereka butuhkan.

Faktanya, sejumlah besar node termasuk dalam persyaratan kedua @reduz untuk dimasukkan ke dalam mesin, hanya karena "Sulit untuk melakukannya sendiri" benar- benar arbitrer. Apa yang mungkin sederhana bagi sebagian orang, sulit bagi orang lain.

Saya tidak berpikir memiliki repositori resmi untuk ekstensi bertentangan dengan "simpul untuk semua kebutuhan Anda". Hanya karena mereka tidak terintegrasi dalam unduhan yang dapat dieksekusi, itu tidak berarti mereka tidak disediakan. Juga, idenya adalah bahwa kebutuhan dasar tercakup dan kekuatan untuk memperluasnya tersedia untuk kebutuhan spesifik game.

Sangat menyenangkan memiliki pengontrol karakter FPS yang out-of-the-box, tetapi tidak ada gunanya bagi semua orang yang tidak melakukan game FPS. Dan dengan menambahkan hal-hal seperti itu, pada dasarnya Anda membuat setiap game yang berisi banyak fitur yang tidak mereka perlukan, meningkatkan biner akhir (yang sangat penting pada target seluler dan web). Harus ada cara untuk menghapus barang-barang yang tidak terpakai dari ekspor akhir, dan menyediakannya secara eksternal berdasarkan kebutuhan adalah salah satu cara (setidaknya sebagian).

Saya setuju bahwa kesulitan itu subjektif. Membuat simpul lengan pegas itu mudah hanya jika Anda sudah mengetahui dasar-dasar untuk menerapkannya. Jika tidak, Anda akan menghabiskan cukup banyak waktu untuk penelitian, yang mengalahkan tujuan menggunakan mesin berfitur lengkap. Metrik yang lebih baik (meskipun masih agak subjektif) adalah "seberapa tingkat rendah" fitur tersebut. Jika perlu menambahkan fungsi ke server fisika atau visual, kemungkinan harus disediakan di mesin. Jika itu hanya perpanjangan dari node yang ada, mungkin bisa di-outsource.

Saya masih percaya bahwa lebih bermanfaat untuk menyediakan node resmi untuk diunduh dan memangkas inti. Dengan ini, kita dapat:

• Memiliki executable kecil untuk editor dan ekspor.
• Sediakan lebih banyak fungsionalitas secara resmi, dengan lebih banyak pembantu khusus game.
• Perbarui dan perbaiki bug di ekstensi tanpa merilis versi mesin baru. Ini berarti node yang dialihdayakan dapat memiliki siklus rilis yang jauh lebih cepat dan merilis patch segera setelah bug diperbaiki.

Namun untuk itu kita masih perlu membuat addons menjadi class citizen yang lebih tinggi dari user-land script. Menggunakan node ekstensi harus terasa seperti menggunakan node inti, sementara tetap jelas bahwa mereka tidak.

Diskusi yang menarik. Banyak proposal bagus juga.

Saya harus mengatakan pertama, bahwa saya menghargai kekompakan biner terakhir, dan bersyukur bahwa ada mesin yang dibuat dengan tujuan itu dalam pikiran. Saya senang visi utama di sini adalah untuk secara aktif memerangi kembung. Setidaknya bagi saya, saya lebih suka hanya memiliki alat yang saya butuhkan untuk pekerjaan yang ada dalam jangkauan.

Hanya ingin menyampaikan anggukan pada beberapa ide menarik ini.

Terutama yang berkaitan dengan semakin banyak fungsionalitas yang diekspor menjadi sesuatu yang berbentuk seperti modul atau plugin resmi.

Dari situ saya membayangkan ini seperti inti dan kemudian perpustakaan modul, dengan yang penting baru saja diinstal secara default. Mungkin banyak yang bisa memilih keluar melalui pengaturan editor. (Saya yakin Zylann menyebutkan mengecualikan 3D untuk game 2D.) Di luar default, modul lain dapat dengan mudah ditemukan dan disertakan.

Meskipun saya bertanya-tanya tentang kesulitan implementasi, karena Anda harus mempertimbangkan apa yang terjadi ketika seseorang mungkin ingin menghapus modul yang aktif dalam proyek. Mungkin harus memperingatkan pengguna untuk menghapusnya dari adegan/skrip tersebut sebelum dapat dinonaktifkan... atau apakah mereka akan tetap menjadi item batu nisan dalam proyek, yang dapat dihidupkan kembali ketika modul ditambahkan kembali?

Ini mungkin bukan hal kecil untuk diterapkan, tetapi saya senang dapat memilih dan memilih fungsionalitas yang disediakan, bila memungkinkan, memungkinkan ekspor game hanya memiliki apa yang dibutuhkan. Lebih banyak kontrol atas itu terdengar berharga bagi saya.

Pemikiran lain dari Vnen tentang memiliki modul dengan beberapa klasifikasi khusus antara built-in dan skrip juga bagus. Ini akan memungkinkan beberapa jenis perilaku dan opsi partisi dan editor lainnya tanpa mengganggu hal-hal baik tentang desain yang ada.

Beberapa mengatakan yay dan beberapa tidak tentang gagasan membuat add-on tampak lebih seperti Godot itu sendiri, tetapi dapat dibayangkan bahwa itu mungkin situasional. Saya juga bisa membayangkan itu dilakukan dengan memecah konsep sedikit. Menyediakan keduanya.

Saya juga tertarik untuk melihat apa yang bisa dilakukan terkait menjaga alat editor dari versi final. Saya telah bekerja keras untuk mencoba memisahkan hal-hal ini, karena bug dan perilaku yang dimaksudkan untuk alat dapat menyusup ke dalam permainan itu sendiri. Terkadang secara destruktif jika Anda melakukan sesuatu dengan memodifikasi data yang akan disimpan.

Pada saat yang sama, saya merasa cukup fantastis untuk dengan mudah memodifikasi fungsionalitas di dalam editor menggunakan skrip alat, jadi lebih banyak perhatian juga akan luar biasa.

Bagaimanapun, tetap bekerja dengan baik semuanya.

Hanya ide gila lainnya:

Mungkinkah mungkin untuk mengonversi GDNative C++ secara otomatis ke modul (idealnya menghapus lapisan tipuan yang dibuat oleh GDNative)? Maka itu mungkin menyenangkan kedua pendukung pendekatan "semuanya dalam satu eksekusi statis" dan pendekatan "fitur strip tanpa menginstal kompiler"

Bagi mereka yang menentang penghapusan node, jika node yang dihapus diimplementasikan dalam GDScript sebagai plugin resmi, bukankah itu lebih baik daripada yang kita miliki saat ini? Karena dengan begitu para pemula dapat benar-benar melihat ke dalam skrip untuk melihat cara kerjanya.

Saya khawatir itu akan merusak kinerja karena GDScript tidak terlalu cepat.

Pada Jumat, 22 Jun 2018 pukul 23:10, Alan [email protected]
menulis:

Bagi mereka yang menentang penghapusan node, jika node yang dihapus adalah
diimplementasikan dalam GDScript sebagai plugin resmi, bukankah itu lebih baik daripada
apa yang kita miliki saat ini? Karena dengan begitu pemula benar-benar bisa mencapai puncaknya
skrip untuk melihat cara kerjanya.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-399628884 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEJES-DWkzuyItQDPbOZgsuN_lA345z7ks5t_b_NgaJpZM4UhqDC
.

@AlansCodeLog Jika benar-benar harus dihapus dan dibuat menjadi ekstensi eksternal, alangkah baiknya memiliki setidaknya versi GDScript , sehingga pengguna tidak perlu mengkompilasi ulang mesin (jika itu adalah file C++ asli) atau menginstal Mono ( jika dikonversi ke GDNative). Namun, sebagian dari respons asli saya (Lihat bagian tentang repositori ekstensi resmi) melibatkan kekhawatiran saya bahwa memasukkannya ke dalam ekstensi hanya akan menciptakan pasar yang aneh ini (karena tidak ada kata yang lebih baik) jika pengguna berhenti mengingat bahwa ada repo ekstensi yang berisi apa yang mereka butuhkan, terlepas dari seberapa resmi atau seberapa mutakhir versi resminya. Add-on baru akan masuk ke pustaka aset yang akan memiliki "Node X dengan Fitur X", "Node X dengan Fitur Y", dan seterusnya ("Node X" mewakili node yang dibuat menjadi ekstensi) -- membuat kekacauan dari add-on yang semuanya mengklaim untuk membantu dengan kendaraan tetapi tidak memiliki tingkat atau pengawasan yang mungkin didapat lebih banyak node resmi.

@LikeLakers2

Tapi kenapa? Pada saat itu, mengapa tidak membiarkan aset memiliki file dependensi ini karena tidak akan membahayakan apa pun?

Saya tidak menentangnya. Tapi karena reduz sepertinya tidak menyukainya, saya sarankan melakukan perbaikan sederhana seperti yang saya sarankan dulu. Lihat bagaimana kelanjutannya, kemudian dapat menambahkan kemampuan untuk aset yang memiliki dependensi nanti. Hanya satu langkah pada satu waktu saran.

Namun, saya menentang gagasan menginstal add-on proyek di lokasi di luar folder proyek karena membuat segalanya lebih sulit untuk dikelola. Hanya add-on editor 'global' yang boleh berada di luar folder proyek.

Setelah beberapa pemikiran lagi, sebenarnya jika fitur inti akan dihapus, dan orang ingin memiliki akses ke fitur inti tersebut [yang kemudian akan menjadi ekstensi] di semua proyek mereka, maka masuk akal untuk dapat menginstal ekstensi tersebut di lokasi global dengan manajemen versi untuk mereka. Tetapi opsi untuk mengunduh dan menginstal ekstensi langsung ke folder proyek juga harus tetap dalam kasus itu. (Sekali lagi, ini seperti opsi npm untuk menginstal secara lokal atau global dengan -g)

Seperti yang dikatakan ribuan tahun di atas, masuk akal untuk memiliki sistem manajemen aset yang lebih baik jika segala sesuatunya harus dihapus dari mesin inti dan diubah menjadi aset. Jika tidak, itu akan berarti fungsionalitas yang hilang dari mesin karena pengguna tidak akan dapat menemukan fungsionalitas yang dihapus dengan mudah.

Saya sedang memikirkan skenario yang ideal untuk

• Pengguna baru dan orang-orang yang tidak mengompilasi mesin: Pada halaman unduhan mesin, mereka memiliki opsi untuk mengunduh mesin inti, dan juga memilih ekstensi resmi atau yang direkomendasikan yang ingin mereka sertakan dalam unduhan mesin mereka. ( Perhatikan bahwa ini tidak akan mungkin jika ekstensi tidak dapat disimpan ke folder global. Pengguna harus menemukan ekstensi setelah mereka membuat proyek, yang membahayakan kemampuan untuk ditemukan. ... Namun, dalam dunia [mustahil] yang ideal, situs web akan buat build C++ khusus dari ekstensi/komponen yang dipilih di tempat.)
• Orang yang mengkompilasi mesin: Alat yang mengelola unduhan dan versi kode C++ ekstensi dan menempatkannya di tempat yang benar di folder build sehingga disertakan dalam build engine.

Sebagai seseorang yang mengkompilasi mesin, saya ingin ekstensi saya sebagai modul daripada GDNative (atau GDScript lebih lambat). Saya membayangkan tingkat modularitas sehingga saya dapat memilih jenis Node tertentu untuk disertakan atau tidak disertakan dalam build saya, atau bahkan menghapus semua barang 3D.

Jika ekstensi C++ semuanya akan menjadi GDNative maka itu membebani pembuat ekstensi yang harus membangun untuk semua platform - yang menurut saya mungkin membuat orang enggan menyiapkannya untuk ekstensi kecil sederhana yang mungkin berguna karena akan terasa berlebihan untuk lakukan semua yang diperlukan untuk mempublikasikannya - dan juga tidak menganjurkan pemisahan fungsionalitas menjadi banyak modul kecil. Saya juga tidak suka fakta bahwa akan ada begitu banyak file dll/pustaka bersama yang ditambahkan ke proyek keluaran.

Di sisi lain, untuk orang yang tidak mengkompilasi mesin, GDNative adalah satu-satunya solusi untuk menambahkan ekstensi C++.

Jadi seperti yang disarankan oleh starry-abyss, jika GDNative dapat diadaptasi secara otomatis menjadi modul normal maka itu akan sangat bagus.

Oke, jadi saya telah mengubah pendirian saya, saya menyukai gagasan mesin bebas mengasapi dengan kemampuan di liga yang sama dengan pembangkit tenaga listrik industri.

Memisahkan semua node ekstra akan memungkinkan banyak keuntungan terutama kemampuan untuk memilih apa yang Anda inginkan dan apa yang tidak.

Berikut adalah beberapa saran saya tentang cara mendekatinya,

1. Pertama kita dapat menambahkan kemampuan ke pustaka aset untuk memiliki aset yang dapat diinstal di bagian, di git mereka dapat dipisahkan oleh tag atau cabang.
   Jadi sekarang jika saya hanya menginginkan Node Fitur 2D, saya dapat mengunduhnya saja tetapi masih hanya memiliki satu tempat untuk melihat untuk memeriksa pembaruan.
2. Kedua, kita dapat menambahkan kemampuan untuk menambahkan label ke pembaruan aset, seperti beberapa pembaruan inti, beberapa fitur, dan beberapa pelanggaran kompatibilitas mundur.
   Ini kemudian dapat digunakan oleh Pengelola Aset secara otomatis untuk memperbarui add-on dan meminta pembaruan kepada Anda tentang masalah tersebut. Seperti itu akan memberi tahu Anda bahwa Anda telah menunggu pembaruan inti, atau pembaruan Anda berikutnya akan merusak kompatibilitas ke belakang. Apakah Anda ingin memperbarui atau tidak.
3. Ketiga untuk memungkinkan memiliki beberapa versi aset dan kemudian ketika versi menjadi terlalu tua, pengembang addon/aset dapat menandainya sebagai usang yang akan tercermin ketika Anda membuka Godot dan itu akan meminta Anda untuk menghapus versi yang lebih lama atau tidak .
4. Dan terakhir kemampuan add-on untuk meminta add-on lain itu akan seperti ketergantungan tetapi itu hanya akan memberi tahu Anda bahwa Anda memerlukan addon ini untuk menjalankan addon ini dan jika Anda tidak menginstalnya.
   Dan jika addon itu sendiri menyadari bahwa addon tersebut tidak dapat ditemukan lagi, mintalah untuk menambahkannya kembali atau hanya menampilkan pesan kesalahan.

Dengan menggunakan metode ini, kita tidak memerlukan manajer ketergantungan tetapi pengembang akan bertanggung jawab atas pekerjaan itu. Jika addon sudah tua dan menggunakan aset/addon yang sudah ketinggalan zaman, kedua pengembang dapat berbicara dan pengembang dapat memutuskan apa yang harus dilakukan.
Dia mungkin hanya port addon-nya dengan cepat. Jika perlu atau dalam beberapa kasus, addon lain dapat menghapus tag yang sudah usang.

Dan seperti yang dikatakan @chanon , kita perlu membuat aset diunduh sebagai global yang kemudian dapat diimpor ke dalam proyek seperti yang dilakukan Unity.
Dan manajer aset yang lebih baik daripada implementasi kami saat ini dengan banyak fleksibilitas ke dalam proses instalasi addon harus diizinkan.
Saya merekomendasikan memiliki kemampuan untuk menambahkan addon baik sebagai GDNative dan Module yang akan membebani pengembang addon tapi saya pikir itu satu-satunya solusi yang dapat diterima kecuali ada sesuatu yang berubah secara radikal di sini.
Tapi kita masih bisa menambahkan beberapa fitur ke GDNative untuk memudahkan pembuatan addon. Seperti bisa membangun untuk semua platform sekaligus akan jauh lebih baik.

Tentang masalah dependensi dan kerusakan aset karena pembaruan plugin,
mengapa tidak (dan maaf jika saya melewatkan seseorang yang sudah menyarankan ini)

1. minta server menyimpan setiap versi yang diunggah

2. izinkan plugin untuk menentukan versi tertentu dari plugin tertentu

3. coba gunakan sistem versi yang waras untuk plugin (Godot sepertinya menggunakan
   Penomoran versi Major.Feature.BugFix, yang saya suka)

4. Dan yang terpenting, bukankah plugin otomatis diperbarui? (Atau setidaknya izinkan
   pengguna untuk memilih jenis pembaruan yang mereka setujui, misalnya perbaikan bug dan
   pembaruan fitur, tetapi tidak ada pembaruan besar).

@Two-Tone Lalu mengapa membuat semuanya bebas mengasapi.??

Kami mengadakan diskusi ini untuk membuat mesin dan seluruh sistem sebebas mungkin tidak memiliki versi yang tidak perlu terbang di sekitar.

Anda benar tentang mengizinkan pengguna memutuskan untuk memperbarui tetapi perbaikan bug harus otomatis secara default. Karena jika saya memiliki ratusan add-on, saya tidak akan memeriksanya satu per satu untuk pembaruan perbaikan bug.
Sisanya bisa terserah pengguna kita bisa memiliki pengaturan untuk menonaktifkan jika perlu.

Dan toko harus menawarkan bundel resmi untuk penggunaan offline (dengan dukungan toko offline di editor).

Saya akan menyarankan satu paket offline berisi beberapa 10-an MB yang berisi demo paling penting dan pengaya paling penting yang seharusnya sangat mudah ditemukan. Tautan font yang lebih kecil di halaman unduhan resmi, seperti tautan untuk versi godot lama, akan sangat bagus.

Mungkin, ya, tetapi di dunia di mana desktop tampaknya tidak menggunakan apa pun yang kurang dari 256BG SSD + 1TB HDD dan bahkan Telepon memiliki ruang mulai dari minimal 16GB yang semuanya kemungkinan besar akan meningkat, apakah itu? BURUK?

Di segmen laptop portabel dan terjangkau, eMMC masih hidup dan baik dan ukuran 32GB (dengan gratis kurang dari 10GB) tidak terlalu umum.

Omong-omong, di kelas laptop itu, saya pikir sistem ekspor Android saat ini bisa digunakan, sedangkan yang direncanakan (https://github.com/godotengine/godot/issues/18865) tidak. Saya memahami manfaat sistem baru dan secara seimbang saya mungkin akan memilihnya sendiri (ketika saya melihat masalah ini, tidak ada kontes), tetapi kita harus menyadari bahwa kita kehilangan kasus penggunaan penting oleh perubahan tersebut.

@swarnimarun Mungkin ada kesalahpahaman. Ketika saya mengatakan "sistem" dalam komentar itu, maksud saya server yang melayani plugin, bukan mesinnya. Maaf jika itu yang membuatmu tersandung.

Jika tidak, maka saya tidak melihat bagaimana mencoba menyelesaikan masalah orang dengan sistem ketergantungan untuk plugin bertentangan dengan mencoba menjaga mesin tetap rendah. Plugin yang disimpan di server untuk berjaga-jaga jika seseorang membutuhkannya tidak berkontribusi pada pembengkakan atau overhead pemeliharaan dan sebagian besar sangat kecil sehingga biaya untuk menyimpannya tidak boleh terlalu tinggi.

@Two-Tone Ya, saya pikir maksud Anda di komputer. Tetapi di server itu baik-baik saja dan itu sudah bisa dilakukan karena Github mengizinkan hash yang dapat disimpan bahkan setelah perubahan dibuat sehingga dalam sistem saat ini bahkan setelah Anda memperbarui repo, Anda harus memperbarui hash di halaman aset.

Tidak hanya github bahkan gitlab dan lainnya juga mengizinkannya. Jika ada orang lain. Git mendukung hash untuk disimpan sebagai ID komit sehingga segala sesuatunya dilakukan dengan cara yang sama.

Hanya beberapa sen saya, cukup yakin sebagian besar telah dikatakan sebelumnya jadi saya ragu saya membawa sesuatu yang baru.

Saya tidak percaya melakukan sesuatu sebagai plugin demi melakukan sesuatu sebagai plugin. Saya mengerti masalah ukuran tapi kita tidak hidup di tahun 80-an lagi. Kita berbicara tentang mesin menjadi 50Mb atau 55Mb, bukan antara mesin menjadi 50Mb atau 500Mb, peningkatan ukuran ekstra dari fitur yang akan dipindahkan ke plugin dapat diabaikan dibandingkan dengan ukuran aset game serius apa pun. Jika harga yang kami bayar adalah integrasi yang lebih merepotkan, itu tidak sepadan.

Ada banyak tempat di mana plugin lebih masuk akal dan dengan arsitektur seperti pematangan GDNative, kita pasti harus mengajukan pertanyaan "apakah ini lebih baik menjadi plugin" dan dalam banyak kasus saya berpendapat jawabannya adalah ya. Satu hal yang saya suka tentang plugin adalah memungkinkan Anda sebagai pengembang lebih bebas dalam banyak hal. Tapi ada juga batasannya.

Pengalaman VR saya menghindari beberapa di antaranya. Ada alasan mengapa ini membutuhkan waktu lebih lama daripada saya ingin mengaktifkan dan menjalankan ini di seluler. Karena tuntutan, terutama di seluler, untuk menyiapkan tampilan dengan berbagai cara, Anda harus mengubah cara kerja inti dan terbukti sulit untuk menangkapnya dalam sebuah plugin.
OpenVR dan OpenHMD sejauh ini adalah yang mudah. Oculus Saya telah melalui solusi yang dipandang rendah tetapi saya senang dengan itu.
ARKit harus berada di inti, itu tidak dapat dipecahkan sebagai modul, setidaknya tidak dalam struktur kami saat ini (Apple bahkan tidak mengizinkan perpustakaan dinamis di iOS jadi ada juga).
GearVR dan Daydream benar-benar harus menjadi inti, sebuah kemustahilan untuk GearVR karena menggunakan perpustakaan kepemilikan.
Hololens/Microsoft MR Saya akan menelusuri rute untuk melihat apakah saya dapat menjadikan ini sebagai pilihan platform, Microsoft melihatnya seperti itu karena aplikasi seharusnya berjalan di antara keduanya dan diinstal pada Hololens sebagai aplikasi holografik saja.

Sekarang AR dan VR adalah fungsi khusus yang sangat sedikit orang akan gunakan, jadi mereka adalah jenis hal yang harus tetap berada di luar inti jika memungkinkan dan saya sangat setuju dengan sudut pandang itu. Tapi saya tidak bisa mengatakan hal yang sama untuk hal-hal lain.

Saya melihat badan kendaraan disebutkan di suatu tempat, serius? Kilobyte kode yang Anda simpan dengan memasukkannya ke dalam plugin? Fisika adalah jenis hal yang menurut saya harus didukung penuh dalam inti IMHO. Saya lebih suka melihat rangkaian lengkap objek fisika terintegrasi penuh di dalam inti daripada harus mencari yang ada di plugin. Sementara pendekatan antarmuka yang mirip dengan ARVRInterface yang kami tulis di GDNative mungkin akan menciptakan integrasi yang solid, saya masih merasa kami hanya membuat hidup menjadi sulit.

Bandingkan dengan mengatakan komponen editor medan, sekarang ada sesuatu yang saya lihat cocok untuk berbasis plugin. Ada berbagai cara berbeda untuk mengatasi medan tergantung pada jenis permainan yang ingin Anda buat sehingga memiliki pilihan antara add-on yang berbeda masuk akal, dan mampu mengembangkan pengembangan independen ini pada intinya, bahkan lebih merupakan alasan.

Singkatnya, di mana plugin masuk akal, dukung plugin, tetapi jangan berlebihan.

Node yang mungkin layak diubah menjadi plugin adalah Control node yang dibuat oleh Control node (yang komposit), hanya menyisakan node sederhana untuk membangun yang lain.

Node dengan logika kompleks seperti Vehicle atau bahkan sederhana namun berguna seperti yang Posisi, bagus dalam inti.

IMO, tidak ada yang harus dikeluarkan dari mesin. Node kontrol, node fisika (seperti Kendaraan), dan bahkan saat ini tidak ada dukungan Medan:

Saya menggunakan Godot karena ini adalah aplikasi yang cukup mandiri dan terintegrasi.
Jika di masa depan saya perlu mengunduh Godot, dan kemudian mencari Vehicle, Control node, dukungan Terrain, editor Shader, plugin Navmesh yang layak dan terus dan terus - menggunakan plugin saat ini dan sistem AssetLib - tidak, terima kasih.

Jika kita pergi dengan cara ini, baik infrastruktur plugin dan AssetLib memerlukan perbaikan kegunaan.

Dan omong-omong, saya jauh lebih tidak terganggu oleh ukuran pemasangan UE4 yang besar daripada jika saya tidak datang dengan dukungan bawaan untuk Kendaraan, Medan atau UI - yang dimilikinya, semuanya.

Saya tidak yakin berapa banyak dari ini yang telah dinyatakan, utas besar seperti ini bisa sulit untuk diikuti, tetapi bagaimanapun:

Saya pikir kita harus fokus pada pengalaman terbaik di luar kotak . Harus masuk ke aset lib, bahkan untuk plugin yang "didukung secara resmi" agak berat.

Ukuran ekspor seharusnya tidak memperburuk kegunaan mesin, IMO. Jika kita perlu mengurangi ukuran ekspor, maka buatlah beberapa fitur untuk menonaktifkan bagian-bagian mesin seperti 3D saat ekspor. Terutama karena saya pribadi tidak menghargai platform seperti seluler dan terutama web, dan saya sedih melihat mesin ditahan oleh mereka dalam diskusi seperti ini. (Saya dapat melihat permintaan untuk mereka, jangan salah paham, meskipun web sekrup)

Sial, jika kita khawatir tentang ukuran unduhan editor maka harus ada unduhan editor "termasuk baterai" dan "minimal". Bagaimana pemisahan diterapkan untuk diperdebatkan, tetapi harus diintegrasikan dengan baik, apa pun yang terjadi.

Saya belum membaca seluruh diskusi secara menyeluruh tetapi saya ingin menyesuaikannya sedikit: kami tidak peduli dengan ukuran. Tentu, menjaga ukuran ekspor tetap kecil pada beberapa platform itu penting, tetapi itu bukan faktor penentu saat mengimplementasikan fitur di mesin. Seperti yang disebutkan, jika beberapa fitur perlu dibuat bersyarat untuk memungkinkan ukuran ekspor kecil, itu sepele. Ukuran unduhan untuk mesin itu sendiri tidak masalah.

Sekarang setelah diselesaikan, faktor utama yang mendorong kami untuk mempertimbangkan untuk menyimpan beberapa barang ("beberapa" untuk ditentukan) keluar dari mesin adalah:

• Utang teknis. Semua kode perlu dipertahankan. VehicleBody yang rusak seperti yang kami miliki sejak 2014 tidak terlalu berguna, karena tidak cukup baik untuk game sungguhan. Baru-baru ini ditingkatkan menggunakan Bullet sehingga menjadi lebih baik, tetapi selama 4 tahun terakhir itu adalah kode mati yang efektif dan beban pemeliharaan yang tidak perlu.
• Universalitas: Godot adalah mesin yang memungkinkan Anda melakukan segala jenis permainan, dan fitur yang disediakannya akan memungkinkan Anda melakukan segala jenis permainan. Ini tidak berarti bahwa itu harus eksklusif (Anda tidak memerlukan 2D dan 3D secara bersamaan di sebagian besar game), tetapi fitur-fiturnya harus memenuhi kebutuhan umum sebagian besar pengguna. Artinya, fitur yang kami sediakan harus level rendah, dan fitur level tinggi khusus game sering kali paling baik disediakan secara eksternal.
• Fleksibilitas: Memiliki fitur tingkat tinggi yang dipertahankan di luar inti memungkinkan proses iterasi yang jauh lebih cepat untuk meningkatkannya, memotongnya jika perlu, dll.

Jika kita pergi dengan cara ini, baik infrastruktur plugin dan AssetLib memerlukan perbaikan kegunaan.

Nah itu raison d'être dari masalah ini, bukan? :) Intinya adalah bahwa kita memerlukan perbaikan kegunaan untuk memungkinkan alur kerja yang lebih baik daripada menggabungkan semua kasus sudut di mesin inti.

Jika seseorang membutuhkan ide untuk memulai fitur eksternal selain VehicleBody, saya ingin mengingat beberapa node dan kelas yang hilang dari godot 2 ke 3: ParticlesAttractor2D (node) dan EventStreamChibi (kelas ini sangat cocok untuk aset eksternal ), saya tahu bahwa penarik partikel tidak kompatibel dengan sistem partikel yang sebenarnya, tapi... Bagaimana dengan memulihkan fungsi godot yang hilang dalam bentuk aset eksternal (Ej, sistem partikel lama hidup berdampingan dengan yang baru....). Mungkin seseorang ingin mempertahankan kode itu di repositori terpisah ...

@Ranoller sistem baru selalu menghapus barang lama, tidak bisa dihindari.
Partikel CPU seharusnya kembali dengan GLES2 (karena tidak mendukung yang CPU), tetapi memiliki penarik pada CPU tetapi tidak pada GPU tidak akan baik.
EventStreamChibi adalah sebuah modul, saya kira sistem audio baru dapat memberikan dukungan yang lebih baik untuk file pelacak jika menjadi lebih fleksibel.

Saya tidak berpikir bahwa bahkan jika kita peduli dengan pemeliharaan, kita harus memisahkan barang-barang dulu.
Kami dapat meminta orang untuk membantu hal-hal yang semakin tua dengan mempostingnya di utas khusus dan kemudian orang dapat memperbarui fitur.
Dengan pertumbuhan yang luar biasa dalam basis pengguna Godot, saya yakin kita akan menemukan banyak orang yang bersedia memperbarui sesuatu dan mengerjakan hal-hal yang semakin tua atau fitur-fitur penting yang hilang dari bagian-bagian mesin, misalnya lebih banyak sambungan.

Jika Anda berpikir bahwa lebih mudah untuk membuat orang bekerja pada file kode yang terpisah maka itu salah kebanyakan tidak akan tahu tentang file-file itu karena tidak akan pernah mendapatkan eksposur yang sama, manajer aset perlu bekerja ya tetapi memiliki fitur sebagai plugin tidak berfungsi dengan baik .
Saya telah melihat beberapa orang beralih dari Unity ke Godot karena terintegrasi dengan baik dan tidak menawarkan fitur penting sebagai plugin.
Dan Unity menyadari bahwa mulai bekerja untuk membuat segalanya lebih terintegrasi dan menambahkan pengembang addon ke tim pengembang Unity.

Jika kita perlu mengunduh Mesin 30MB dan kemudian membuang waktu mengunduh fitur terpisah sebagai plugin yang mungkin lupa saya tambahkan ke proyek saya, maka saya mungkin tidak menggunakannya sejak awal. Yang merupakan masalah bagi seorang pemula.

Mengenai utang teknis, ini adalah masalah yang pada akhirnya harus dihadapi oleh setiap proyek (FOSS atau komersial). Yang benar adalah bahwa beberapa pengembang akhirnya pergi dan suatu area tidak lagi mendapatkan banyak perhatian (sehingga harus ditempatkan ke mode "pemeliharaan" sampai seseorang tertarik). Seperti yang saya sebutkan, ini bahkan terjadi pada aplikasi komersial besar. jadi itu pasti akan terjadi dengan Godot, tidak peduli berapa banyak pemangkasan yang didapat mesin.

Solusi terbaik di area itu adalah dengan hanya mengembangkan adegan pengembangan yang mendorong orang untuk mulai berkontribusi pada sumbernya (dan adegan Godot telah melakukan pekerjaan yang baik ketika melihat semua pengembangan sukarelawan, tetapi itu harus terus dipertahankan melalui hal-hal seperti memastikan kontributor tambalan tidak menunggu lama untuk melihat ulasan). Namun, penghapusan fitur karena pengembang pergi harus dihindari jika memungkinkan (karena daftar fitur yang terus berfluktuasi akan menjadi cara yang bagus untuk meyakinkan orang _untuk tidak menggunakan_ Godot sama sekali). Sebaliknya, penghapusan fitur terutama harus terjadi karena digantikan oleh sesuatu yang lebih baik.

Namun, penghapusan fitur karena pengembang pergi harus dihindari jika memungkinkan (karena daftar fitur yang terus berfluktuasi akan menjadi cara yang bagus untuk meyakinkan orang untuk tidak menggunakan Godot sama sekali). Sebaliknya, penghapusan fitur terutama harus terjadi karena digantikan oleh sesuatu yang lebih baik.

Sekali lagi, diskusi berjalan ke arah yang salah jadi saya akan mencoba mengarahkannya kembali ke jalur yang benar. Topiknya bukan tentang menghapus barang, ini tentang mencegah penambahan hal baru yang mungkin ingin kami hapus. Karena menambahkan barang sangat mudah, tetapi kemudian kami tidak dapat menghapusnya tanpa merusak kompatibilitas.

Seiring pertumbuhan Godot, semakin banyak kontributor baru datang dengan tambahan yang mungkin tidak sesuai dengan arsitektur atau desain yang kami inginkan untuk diikuti oleh mesin. Meninjau semua perubahan itu membutuhkan banyak waktu, dan terlebih lagi memutuskan apakah itu sesuai dengan yang kita inginkan. Menggabungkan fitur-fitur baru tersebut oleh kontributor baru akan menghasilkan kode yang tidak diketahui dengan baik oleh pengelola mesin atau mungkin tidak sepenuhnya disetujui pada akhirnya, dan kontributor asli mungkin sering tidak bertahan untuk memfaktorkannya kembali dan memastikannya sesuai dengan yang kita inginkan (lihat misalnya simpul Tween, yang merupakan fitur hebat tetapi dengan desain di bawah standar, dan penulis aslinya sudah tidak ada lagi, jadi terserah kita untuk memikirkan kembali dan menulis ulang, melanggar kompatibilitas di tengah jalan).

Jadi inti dari proposal @reduz adalah bahwa semakin banyak fitur yang ingin dimasukkan oleh kontributor baru ke dalam mesin inti, sebagian besar waktu, akan lebih cocok sebagai aset di perpustakaan aset. Inti dari masalah ini di sini adalah bagaimana memastikan alur kerja ini bisa semulus mungkin.

Kami tidak mencoba mengecilkan basis kode Godot, kami berpikir tentang bagaimana melindungi kami agar tidak meledak dan lepas kendali. (Karena kontributor satu kali dengan PR besar jauh lebih sering daripada pengelola mesin dengan pemahaman menyeluruh tentang basis kode lengkap dan visi yang kami miliki untuk masa depan mesin).

Jadi inti dari proposal @reduz adalah bahwa semakin banyak fitur yang ingin dimasukkan oleh kontributor baru ke dalam mesin inti, sebagian besar waktu, akan lebih cocok sebagai aset di perpustakaan aset. Inti dari masalah ini di sini adalah bagaimana memastikan alur kerja ini bisa semulus mungkin.

Saya harus bertanya, apa yang akan membuat ini menjadi aset di perpustakaan aset kecuali memindahkan masalah ke belakang selangkah? Anda beralih dari kode yang dibundel dengan Godot yang tidak lagi dipertahankan, ke kode dalam aset Godot yang tidak lagi dipertahankan. Either way, kontributor asli mungkin akan berhenti mempertahankannya di beberapa titik dan akhirnya akan rusak lagi.

@LikeLakers2 Nah, tujuannya adalah untuk menciptakan jalan yang mulus bagi kontribusi baru yang akan ditambahkan untuk mesin (karena sebagian besar yang lebih terkait aset ditolak untuk saat ini). Jika beberapa aspek dari mesin tidak dipertahankan, maka itu tidak boleh digabungkan dengan mesin di tempat pertama karena kembung murni pada saat itu. Hal-hal seperti itu sangat cocok sebagai plugin yang disertakan/diperbarui secara eksternal.

Jika di masa depan saya perlu mengunduh Godot, dan kemudian mencari Vehicle, Control node, dukungan Terrain, editor Shader, plugin Navmesh yang layak dan terus dan terus - menggunakan plugin saat ini dan sistem AssetLib - tidak, terima kasih.

Tepat. AssetLib/add-on secara umum tidak berfungsi dengan baik sekarang untuk ini, oleh karena itu mengapa percakapan cenderung menyimpang ke sana. Saya tidak berpikir ada orang yang ingin mengeluarkan barang saat ini juga, tetapi seperti yang telah disebutkan intinya adalah tentang tidak menambahkan terlalu banyak barang baru.

Saya harus bertanya, apa yang akan membuat ini menjadi aset di perpustakaan aset kecuali memindahkan masalah ke belakang selangkah? Anda beralih dari kode yang dibundel dengan Godot yang tidak lagi dipertahankan, ke kode dalam aset Godot yang tidak lagi dipertahankan. Either way, kontributor asli mungkin akan berhenti mempertahankannya di beberapa titik dan akhirnya akan rusak lagi.

Yah, saya berasumsi akan lebih mudah jika mereka bisa dikelola lebih terpisah dari mesin. Blender melakukan sesuatu seperti ini. Mereka memiliki add-on "resmi" (tidak benar-benar resmi, hanya disertakan sebelumnya), tetapi kode mereka disimpan dalam submodul git yang terpisah, dan ketika mereka menjadi tidak dikelola oleh orang-orang yang mengirimkannya (saya pikir Anda harus mengirim ulang dengan setiap rilis besar), mereka dijatuhkan. Meskipun sejujurnya saya tidak terlalu menyukai pendekatan ini, saya berharap mereka hanya memiliki browser aset bawaan untuk 90% barang dan langsung mengintegrasikan sisanya (hal-hal seperti eksportir).

Saya pikir idenya adalah bahwa mesin hanya akan memiliki blok bangunan dasar yang disertakan, kemudian hal-hal seperti simpul kendaraan bisa menjadi pengaya resmi, lalu segala sesuatu yang lain yang besar dan dapat diimplementasikan dengan cara yang berbeda seharusnya hanya pengaya biasa. , Baik?

Apa yang saya tidak mengerti adalah bagaimana pengaya resmi akan diimplementasikan. Saya pikir saat ini kami tidak dapat menulis simpul khusus yang terlihat seperti bawaan, kan, mereka harus memiliki skrip? Atau apakah itu mungkin dengan modul c++ atau sesuatu (saya c++ noob di sini).

Dan juga akhirnya kita masuk ke masalah bagaimana memiliki add-on yang tergantung pada node resmi yang terpisah. Tanpa semacam sistem ketergantungan, kedengarannya seperti neraka.

Terlambat ke pesta, tetapi mengingat skala proyek saya saat ini, saya mendapati diri saya mengembangkan _banyak_ plugin untuk Godot 3 dan melihat diri saya mengembangkan lebih banyak lagi sebelum proyek selesai. Dengan setiap plugin, saya mencoba mengembangkan sebanyak yang saya bisa dengan cara agnostik game dan membukanya di bawah lisensi MIT untuk digunakan orang lain. Saya tidak akan berbohong. Sistem addon saat ini sebenarnya tidak terlalu buruk dalam skema besar... NAMUN ada _are_ beberapa bagian yang hilang yang membuatnya batas tidak berguna dalam banyak kasus. Namun, sebelum saya membahasnya, saya ingin mengatakan beberapa hal tentang ide @karroffel .

Pertama, terima kasih telah menyatukan masalah ini. Saya pikir diskusi ini penting--terutama dalam waktu dekat. Yang mengatakan, saya pikir setiap poin diskusi yang Anda sajikan dalam OP sebagian besar ortogonal dengan hanya tumpang tindih tangensial. Saya pikir kita bisa sangat banyak beralih pada solusi di sini tanpa harus mengatasi semua masalah sekaligus.

Ini membawa saya ke keraguan _personal_ saya dengan sistem addon saat ini dan apa yang saya pikir akan menjadi dua titik awal yang sangat baik untuk dunia yang lebih baik dari seseorang yang benar-benar mengembangkan plugin secara reguler:

Masalah terbesar tunggal dengan sistem addons saat ini adalah kurangnya manajemen ketergantungan.

Ini sudah banyak dibahas, tetapi sebagian besar saran agak berat dan tidak terlalu kompatibel dengan sistem saat ini. Sekarang, saya belum membiasakan diri dengan basis kode modul asetlib, tetapi saya pikir _seharusnya_ ada kemenangan mudah di departemen ini. Saat ini, repositori addon bagian ke-3 di Github mematuhi struktur folder berikut:

addons/
    addon_name/
        plugin.cfg
        ...other files

Apa yang saya usulkan adalah untuk memperluas skema plugin.cfg dan menambahkan kemampuan untuk hanya memiliki daftar versi ketergantungan dengan opsi commit hash (atau nama cabang/tag) untuk digunakan. Sesuatu seperti berikut ini akan berfungsi:

[plugin]
name="foo"
description="foobar"
author="blah"
version="1.0.0"
script="plugin.gd"

[dependency]
name="dep1"
path="github.com/foo/dep1"
hash="7fc2367508c41cfab86eaf7d84e04cd122978fdb"

[dependency]
name="dep2"
path="github.com/foo/dep2"
tag="v3.1.2"

[dependency]
name="dep3"
path="github.com/foo/dep3"
branch="big-refactor"

Kemudian, ketika pustaka aset pergi untuk menginstal aset, pertama-tama ia mengunduh proyek ke direktori addons seperti saat ini, kemudian mengunduh setiap dependensi (menggunakan hash atau cabang yang benar yang ditentukan) dan meletakkannya di direktori addons juga . Sebagai langkah pertama, konflik ketergantungan dapat diabaikan atau membiarkan pengguna memilih mana yang akan digunakan. Ini bukan solusi _ideal_, tapi saya pikir ini akan berhasil dalam banyak kasus dan setidaknya menahan kami sampai perombakan asetlib yang lebih terlibat dilakukan. (kecuali seseorang dapat menemukan cara sederhana untuk menangani konflik ketergantungan dari atas kepala mereka).

Sebagai contoh dunia nyata,
Saya memiliki aset untuk pohon perilaku godot. Bagian dari sistem ini adalah node Blackboard seperti UE4 untuk menyimpan data global atau lokal node yang arbitrer yang akan dibagikan di seluruh node. Ini digunakan dalam sistem BT untuk berbagi status antara node perilaku. Itu semua bagus dan keren, tapi kemudian saya sedang mengembangkan sistem dialog dan perkakas yang menyertainya, dan bagian dari sistem ini memerlukan semacam database varibal untuk digunakan untuk kondisi. Saya sangat ingin menggunakan kembali komponen papan tulis dari sistem BT untuk sistem dialog juga. Faktanya, komponen Blackboard sama generiknya dengan yang didapat, dan data global adalah idiom yang cukup umum di gamedev, jadi meskipun sendiri ini bisa menjadi addon yang cukup berguna, karena ini adalah salah satu yang diimplementasikan kembali pada dasarnya di setiap proyek. .

Dengan sistem ketergantungan yang tepat, saya dapat memecah komponen Blackboard menjadi addonnya sendiri dan kemudian menggunakan kembali komponen ini di semua addon BT, addon sistem dialog, dan penggunaan khusus game apa pun yang saya miliki untuk itu. Sepertinya apa yang saya maksud?

Kebutuhan akan node multi-skrip

Ini adalah topik hangat lainnya dalam masalah ini, dan sejujurnya, saya tidak memiliki cara yang baik untuk mendekati ini tanpa mengubah ideologi dasar tentang bagaimana Godot dimaksudkan untuk digunakan. Ini mungkin atau mungkin tidak baik-baik saja, tapi ya... Bagaimanapun, ini bukan masalah untuk plugin _authors_ seperti untuk plugin _users_ (sering kali orang yang sama ;).

Pada akhirnya, jika kita dapat menyelesaikan dua hal ini, saya pikir kita akan mencapai 90%. 10% lainnya bukan masalah besar menurut saya dan mungkin harus didekati dari perspektif merombak arsitektur fundamental aset, yang menurut saya, bisa menunggu setelah menggoreng ikan yang jauh lebih besar.

Jika tidak ada keberatan, saya mungkin akan mencoba menerapkan saran saya mengenai manajemen ketergantungan dalam kode assetlib dalam beberapa hari mendatang

manajemen ketergantungan terdengar keren bagi saya. :senyum:

Satu-satunya hal yang saya tidak setuju adalah memiliki versi ketergantungan
menjadi daftar opsional. Itu akan menyebabkan masalah reduz yang disebutkan itu
terjadi dengan sistem plugin mesin lain.

kecuali seseorang dapat menemukan cara sederhana untuk menangani konflik ketergantungan dari atas kepala mereka

Saya pikir solusi untuk itu akan tergantung pada bagaimana plugin memanggil kode dari
plugin yang berbeda. Jika kami mengaturnya agar skrip plugin melakukannya
extends "dep2/folder/script.gd" , saat menginstal kita bisa mengubah dep2
ke dep2-v3.1.2 . Untuk hash kita bisa menggunakan 5 digit pertama (kecuali
kami ingin folder dengan nama yang panjangnya setidaknya 42 karakter). Pukul 5
digit kemungkinan tabrakan sangat kecil.

Saya sedikit lelah sekarang, jadi saya mungkin melewatkan sesuatu, tetapi saya tidak melihat
ada masalah.

@jonbonazza jika Anda melakukannya, cobalah untuk tidak meng-hardcode penggunaan Git di dalamnya. Meskipun kedengarannya seperti diberikan di sini, beberapa orang mungkin lebih suka sistem VCS lain (atau tidak menggunakan VCS sama sekali), jadi mungkin itu harus menjadi detail yang harus ditangani di sisi aset-lib.
Juga, saya ingin tahu apakah kami mempertimbangkan untuk melakukan sesuatu untuk mempermudah memiliki plugin sebagai sub-repos VCS dalam sebuah proyek? Disebutkan di beberapa titik tetapi saya tidak ingat apakah ada kesepakatan.

Ya, saya pikir hanya id aset dan versinya saja sudah cukup.

Menentukan repositori/cabang/tag/hash Git mungkin merupakan cara opsional untuk menentukan ketergantungan, tetapi cara utamanya harus dengan id aset.

Saya tidak yakin apakah perpustakaan aset memiliki id unik yang dapat dibaca manusia (siput). Jika tidak seharusnya. Misalnya modul npm memiliki nama/id modul teks yang Anda gunakan saat menginstalnya.

Spesifikasi ketergantungan mungkin akan terlihat seperti

[dependency]
asset_id="some_asset"
version="1.0.0"

@Two-Tone Saya berusaha untuk tidak terlalu gila dengan ini. Hanya ingin sesuatu yang sederhana untuk menahan kita sampai pendekatan yang lebih baik diputuskan.

@Zylann Saya mungkin akan menggunakan pendekatan yang sama yang saat ini digunakan di aset lib--mengunduh dan mengekstrak file Zip dari github.

@chanon aset lib terhubung dengan github secara langsung sehingga satu-satunya identifikasi yang kami miliki untuk versi adalah komit hash, cabang, dan tag.

Bagian mana yang terlalu gila? Memiliki versi ketergantungan wajib atau solusi saya
untuk konflik ketergantungan? Satu adalah standar di sebagian besar tempat yang memiliki
manajemen ketergantungan dan yang lainnya adalah pengeditan sederhana untuk teks dan folder
bernama. Saya tidak berpikir salah satu dari hal-hal itu gila.

Pada Selasa, 3 Juli 2018, 11:23 Jon [email protected] menulis:

@Two-Tone https://github.com/Two-Tone Saya berusaha untuk tidak terlalu gila
dengan ini. Hanya ingin sesuatu yang sederhana untuk menahan kita sampai lebih baik
pendekatan diputuskan.

@Zylann https://github.com/Zylann Saya mungkin akan menggunakan pendekatan yang sama
yang saat ini digunakan di aset lib--mengunduh dan mengekstrak zip
file dari github.

@chanon https://github.com/chanon aset lib berputar dengan github
secara langsung sehingga satu-satunya identifikasi yang kami miliki untuk versi adalah hash komit,
cabang, dan tanda.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-402214905 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEJES-_IJBjvj3ImvZnqdu-cIAunCp2gks5uC5qIgaJpZM4UhqDC
.

@Two-Tone maaf, tapi "terlalu gila" maksud saya "terlalu rumit" karena ini seharusnya menjadi perbaikan cepat untuk menahan kita. Saya setuju bahwa dalam jangka panjang, penyelesaian konflik yang tepat diperlukan, tetapi saya berharap kita bisa lolos tanpa itu untuk sementara.

Pilihan lain adalah dengan mengabaikan semua asetlib dan hanya git mengkloning deps langsung ke dalam proyek, meskipun karena struktur proyek plugin de facto saat ini di-root pada direktori addons , ini tidak akan benar-benar berfungsi. Kami membutuhkan root proyek menjadi satu tingkat lebih dalam (yaitu mengecualikan direktori addons dan di-root pada nama plugin). Sejujurnya saya pikir ini akan menjadi perubahan yang disambut baik, karena Anda dapat menggunakan submodul git untuk dependensi.

@jonbonazza saya mengerti. Solusi Anda adalah sesuatu yang dapat diterapkan dan langsung berfungsi tanpa perlu memodifikasi Pustaka Aset. Maka saya setuju itu adalah langkah pertama yang baik. (Bukannya saya adalah pengelola inti yang memiliki otoritas apa pun.. hanya saja menurut saya itu adalah langkah awal yang baik.)

Saya pikir jika database Perpustakaan Aset memiliki pengenal teks (siput) ditambah informasi versi yang ditambahkan, maka itu dapat ditambahkan seperti contoh saya di atas.

anda dapat menggunakan submodul git untuk dependensi.

@jonbonazza dan di situlah pertanyaan terakhir saya muncul lagi, karena sepertinya tidak mungkin menggunakan submodul dengan repro plugin karena repo itu perlu menyertakan hierarki file lengkap agar sesuai untuk diunduh, memaksa .git folder

@chanon tepatnya. Itu hanya akan membutuhkan sejumlah kecil kode tambahan dalam beberapa file. Sejujurnya, sebuah addon mungkin dapat dikembangkan yang dapat melakukan ini untuk Anda alih-alih membangunnya ke dalam asetlib

@Zylann ya itulah yang saya maksudkan dalam komentar saya tentang submodul. Saat ini tidak mungkin karena pembatasan saat ini pada struktur proyek, tetapi mengubah aset lib menjadi lebih fleksibel dalam hal ini akan menjadi sepele.

EDIT: Itu bisa dilakukan dengan cara yang kompatibel juga.

Saya sebenarnya membuat proposal mengenai struktur proyek beberapa waktu lalu. Itu sebenarnya keluhan utama saya tentang cara kerja plugin sekarang. Tidak ada cara yang bagus untuk mengemasnya. Lihat #18131. Itu benar-benar harus diubah terlebih dahulu, imo, sebelum apa pun, dan semakin cepat semakin baik, jadi kami memiliki lebih sedikit orang yang harus mentransisikan plugin mereka.

Apa yang rumit tentang itu? Salah satunya adalah persyaratan yang dapat ditegakkan dengan
cek sederhana dan yang lainnya adalah pertandingan dan penggantian sederhana atau
tambahkan/tambahkan. Ini lebih sederhana daripada benar-benar menambahkan dukungan ketergantungan.

Pada Selasa, 3 Juli 2018, 12:11 Jon [email protected] menulis:

@Two-Tone https://github.com/Two-Tone maaf, tapi "terlalu gila" maksud saya
"terlalu rumit" karena ini seharusnya menjadi perbaikan cepat untuk menahan kita.
Saya setuju bahwa dalam jangka panjang, resolusi konflik yang tepat diperlukan, tapi
Saya berharap kami bisa lolos tanpa itu untuk sementara.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-402229111 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEJES7c8ziwhXZirsTsLY0zWfI-jrBzmks5uC6XUgaJpZM4UhqDC
.

@Two-Tone Anda tidak bisa hanya mengganti nama folder karena skrip dalam kode plugin sering menggunakan jalur addon secara langsung. Misalnya

extends "res://addons/foo/bar.gd"

@jonbonazza Saya akan menambahkan, bukan hanya skrip yang melakukan itu, tetapi sumber daya apa pun yang merujuk ke yang lain.

Kemudian buat struktur folder add-on seperti yang saya katakan tetapi wajib, lalu di
waktu instal cukup gunakan fungsi temukan dan ganti yang ada di kelas String
ada di setiap skrip yang harus dicari

'memperpanjang " res://addonname/ '

Dan ganti dengan

'memperpanjang " res://addonname-versionnumber/ '

Ini bukan masalah sulit dalam kode. Mereka sangat sederhana berkat c++.
Ini sebagian besar hanya masalah pengguna untuk memastikan masalah ini diperbaiki
kita harus mengamanatkan beberapa hal. Jika mereka mengunggah plugin dan pengguna menemukan itu
itu benar-benar rusak karena dev tidak mengikuti ini dengan luar biasa
aturan sederhana, maka itu ada di pengembang plug-in.

Dan kita harus mengamanatkan aturan untuk memulai, jadi kita mungkin juga
sertakan ini atau beberapa bentuk ini untuk memastikan kami melakukan ini dengan benar
dari awal.

Pada hari Rabu, 4 Juli 2018, 12:48 Marc [email protected] menulis:

@jonbonazza https://github.com/jonbonazza Saya akan menambahkan, ini bukan hanya
skrip yang melakukan itu, tetapi aset apa pun yang mereferensikan aset lain.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-402533781 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEJESwoMKvVVXcllrQ4YQQO852oZ1v7rks5uDP_SgaJpZM4UhqDC
.

Saya kira jika plugin merusak kompatibilitas setelah pembaruan, mereka harus memberikan fallback penghentian, atau melakukan seperti yang dikatakan @Two-Tone, dengan sengaja memutus jalur dengan mengganti nama plugin atau subfoldernya (itu akan menjadi skenario terburuk karena itu bukan situasi yang menyenangkan). Begitulah cara mesin itu sendiri, dan yang lain melakukannya. Menulis sebuah plugin hadir dengan pola pikir yang sangat berbeda bahwa orang/plugin lain yang tidak Anda kenal akan bergantung padanya.

Apa yang dipecahkan ini bukanlah masalah ketergantungan tetapi solusi untuk konflik ketergantungan. Satu plug-in mungkin bergantung pada versi 1 dari add-on yang berbeda dan yang lain mungkin bergantung pada versi 2, tanpa ini atau yang serupa dengannya, kami akan mengalami konflik atau harus membatasi pengguna agar tidak dapat menggunakan plugin yang memiliki ketergantungan yang saling bertentangan.

Dan solusi untuk mencegah pembaruan agar tidak merusak kompatibilitas adalah dengan memberlakukan bahwa setiap pembaruan harus memiliki nomor versi yang unik. Namun, itu mungkin mulai masuk ke dalam kategori "terlalu rumit" karena Anda harus mengurai plugin.cfg lalu bertanya kepada server aset apakah sudah ada plug-in dengan nama dan nomor versi itu. Jika ada, lempar kesalahan. Jika tidak, semuanya harus baik-baik saja.

Dan saya tidak yakin apakah Anda berbicara tentang skrip di plug-in atau skrip yang ditulis pengguna, tetapi bagaimanapun saya setuju bahwa itu agak berat tetapi seharusnya tidak menjadi masalah yang sulit.

Satu-satunya solusi yang dapat saya pikirkan adalah memperluas gdscript sehingga pengguna dapat menentukan dalam skrip apa versi plugin yang mereka gunakan, kemudian sejak saat itu mereka hanya melakukan extends "res://addonname/etc dan membuat mesin itu sendiri menangani penggunaan jalan yang benar. Namun, itu pasti termasuk dalam masalah "terlalu rumit" yang disebutkan oleh @jonbonazza . Tapi untuk jangka pendek bisa dilewati.

Ada masalah lain yang pada akhirnya perlu diselesaikan. EG pengguna harus tahu dependensi apa yang sedang diinstal, bagaimana menangani beberapa folder di browser sistem file internal yang berasal dari pemecahan masalah konflik dependensi, bagaimana kita menangani plug-in yang merupakan dependensi tetapi memiliki pembaruan (apakah kita menerapkan pengaturan yang sama yang digunakan untuk plug-in yang diinstal secara manual?misalnya menginstal otomatis perbaikan bug atau hanya menginstal pembaruan ketika plug-in utama memperbarui daftar dependensinya), dan lebih banyak lagi saya yakin.

Saya benar-benar dapat melihat mengapa @reduz merasa bahwa manajemen ketergantungan itu tidak penting. Ada begitu banyak variabel yang _ perlu _ dipertimbangkan dan diselesaikan agar ini layak dimasukkan ke dalam Godot atau kita akan berakhir dengan sistem yang tidak lebih baik dari apa yang digunakan mesin lain.

Sejujurnya, saya pikir tindakan terbaik untuk solusi jangka pendek adalah mengubah lib aset untuk mendukung (meskipun tidak _memerlukan_ karena kompatibilitas mundur) kemampuan untuk melayani proyek yang berada satu lapisan di bawah direktori addons . Misalnya

godot-tools.level-streamer/
    project.cfg

Dari pada

addons/
    godot-tools.level-streamer/
        project.cfg

Dengan cara ini, kita bisa menentukan dalam deskripsi addon yang memerlukan addon lain.

Itu juga akan memungkinkan kita untuk dengan mudah menggunakan gitsubmodules di proyek kita untuk add-on sebagai gantinya jika kita mau.

Bagaimana dengan melakukan itu untuk deps (misalnya dep/ ) kemudian memiliki plug-in yang diinstal secara manual di direktori root atau folder yang ditentukan pengguna? Dengan begitu dependensi tidak mengacaukan root dan addons dapat berada di salah satu atau?

$UserSetLocation/
    godot-tools.level-streamer/
        project.cfg

deps/
    thing-level-streamer-uses/
        project.cfg

@Two-Tone Tapi lalu bagaimana jika ketergantungan Anda memiliki ketergantungan? Bukankah folder deps seharusnya menjadi subfolder dari plugin itu sendiri, dengan begitu Anda bisa masuk sedalam yang diperlukan?

Saya merasa seluruh masalah ketergantungan ini terlalu dipikirkan. Mungkin kita harus membuat beberapa sistem sederhana dan berdiskusi tentang masing-masing, atau memilih? Saya tidak memperkirakan percakapan ini akan berakhir dengan arahnya saat ini.

Yang telah dibilang...

@willnationsdev Itu bisa berhasil, tetapi jika banyak plugin bergantung pada ketergantungan yang sama, maka Anda memiliki banyak salinan ketergantungan itu di mana mungkin hanya perlu seperti... dua.

Ya, manajemen ketergantungan bukanlah hal yang sederhana. Jika tidak, npm tidak perlu serumit itu dan yarn tidak perlu dibuat.

Saya tidak berpikir menempatkan dependensi sebagai subfolder aset adalah ide yang bagus karena mengarah ke jalur yang akan sangat kompleks. Akan ada kasus ketika 2 atau lebih aset memiliki ketergantungan yang sama dan beberapa jenis deduplikasi akan diperlukan. Juga, saya pikir lebih baik bagi pengembang game untuk melihat dengan tepat dependensi apa yang dimiliki proyek, daripada harus melalui subfolder dari subfolder untuk mengetahui dependensi mana yang digunakan dan/atau digandakan n kali karena ini adalah ketergantungan umum.

Di web dev node.js, misalnya, boleh saja mengabaikan apa yang ada di dalam node_modules selama itu berfungsi karena hanya akan digunakan di server. Untuk sebuah game, Anda akan mengemas semua kode/aset itu ke dalam paket aplikasi akhir dan memiliki ketergantungan yang sama yang diduplikasi n kali cukup buruk.

Masalah-masalah ini adalah mengapa saran awal saya mengatakan untuk tidak membiarkan aset menentukan dependensi, tetapi hanya memiliki cara untuk membuat daftar dependensi proyek, dan biarkan pengguna menginstal dependensi aset secara manual:
https://github.com/godotengine/godot/issues/19486#issuecomment -399559419

Jika kita memiliki aset yang menentukan dependensi, maka saya pikir mereka semua harus diinstal pada level yang sama (di folder res://addons ). Untuk konflik versi ketergantungan (dua aset bergantung pada aset yang sama tetapi versinya berbeda) saya pikir resolusi sederhana akan menjadi yang terbaik, seperti selalu menggunakan versi yang lebih baru.

Di sisi lain, jika kita benar-benar ingin menerapkan manajemen ketergantungan dengan deduplikasi dan resolusi konflik versi dengan mengizinkan beberapa versi dari aset yang sama untuk diinstal, maka tidak apa-apa juga! Seolah benar-benar dibuat kokoh, maka akan mampu mendukung perluasan ekosistem aset jangka panjang. Entah bagaimana saya tidak menyukai gagasan memiliki beberapa versi dari aset yang sama dalam proyek game saya. Dan butuh npm begitu banyak versi sampai mereka melakukannya dengan benar (meskipun saya masih lebih suka yarn ) jadi saya tidak berpikir tugas ini harus diremehkan.

Saya tidak berpikir menempatkan dependensi sebagai subfolder aset adalah ide yang bagus karena mengarah ke jalur yang akan sangat kompleks.
Jika kita memiliki aset yang menentukan dependensi, maka saya pikir mereka semua harus diinstal pada level yang sama (di folder res://addons

Saya setuju dengan itu. Saya juga lebih suka add-on ada sekali di proyek di lokasi standar, tidak sebanyak versi yang diperlukan oleh berbagai sumber lain dan di berbagai folder. Ketergantungan adalah suatu hal, tetapi kita dapat menemukan jalan tengah juga alih-alih menjadi berbutir halus maksimum, untuk menjaga agar semuanya tetap sederhana.

Masalah-masalah ini adalah mengapa saran awal saya mengatakan untuk tidak membiarkan aset menentukan dependensi, tetapi hanya memiliki cara untuk membuat daftar dependensi proyek, dan biarkan pengguna menginstal dependensi aset secara manual.

Bagi saya jika aset menentukan dependensi, pengguna akan lebih cepat mendapat informasi daripada harus melihat dokumen atau meninjau semua plugin sebelum menginstal. Dan akhirnya, memiliki opsi untuk mengunduh dependensi pada saat yang sama, tetapi hanya untuk kenyamanan (terutama ketika Anda menginstal dari awal, Anda tetap harus menginstalnya). Kami mungkin tidak perlu menyelesaikan konflik ketergantungan juga, setidaknya alat penginstalan dapat memberi tahu pengguna jika dapat mendeteksinya.

Saya merasa seluruh masalah ketergantungan ini terlalu dipikirkan

@LikeLakers2 Manajemen ketergantungan yang tepat dan penghindaran konflik adalah masalah yang penting dan sulit. Itu sedang banyak dibahas karena itu

Saya tidak memperkirakan percakapan ini akan berakhir dengan arahnya saat ini.

Mencoba untuk mendorong ini tanpa memikirkan semua masalah yang ditimbulkan oleh ketergantungan akan menjadi ide yang sangat buruk dan hanya menyebabkan lebih banyak masalah. Ini adalah masalah yang sulit dan akan memakan waktu.

Untuk konflik versi ketergantungan (dua aset bergantung pada aset yang sama tetapi versinya berbeda) saya pikir resolusi sederhana akan menjadi yang terbaik

@chanon Ide saya sederhana. Apa yang rumit tentang penamaan folder dan mengubah jalur file yang relevan dalam dokumen teks? Ini adalah biaya satu kali bagi pengguna, membuatnya jelas versi apa dari apa yang telah Anda instal, dan cukup mudah untuk ditulis.

seperti selalu menggunakan versi yang lebih baru

Itu akan menyebabkan plug-in putus tanpa peringatan saat dependensinya diperbarui dan mengubah cara kerjanya. EG Plugin 1 dan 2 keduanya bergantung pada Dep 1, tetapi versinya berbeda. Plugin 2 bergantung pada versi terbaru saat ini, tetapi plugin 1 bergantung pada versi lama yang berperilaku berbeda dari versi terbaru. Plugin 1 tidak lagi berfungsi sebagaimana mestinya atau memiliki bug yang tidak disertakan.

Kami mungkin tidak perlu menyelesaikan konflik ketergantungan juga, setidaknya alat penginstalan dapat memberi tahu pengguna jika dapat mendeteksinya.

@Zylann Kemudian kami memiliki masalah di mana pengguna tidak dapat menginstal x plugin karena y menggunakan versi berbeda dari ketergantungan yang sama. Itu tidak akan dianggap sebagai hal yang baik oleh pengguna

Saya setuju dengan @willnationsdev dan @LikeLakers2

Saya merasa seluruh masalah ketergantungan ini terlalu dipikirkan. Mungkin kita harus membuat beberapa sistem sederhana dan berdiskusi tentang masing-masing, atau memilih? Saya tidak memperkirakan percakapan ini akan berakhir dengan arahnya saat ini.

Terlalu banyak kehilangan sepeda. Ini adalah game engine, bukan game-engine-addon-delivery-platform. Hanya dependensi vendor di setiap direktori addons dan sebut saja sehari. Tidak ada tekanan tentang konflik versi atau manajemen atau dengan biaya beberapa inefisiensi. Jika pengguna addon khawatir tentang kinerja, maka mereka harus berada dalam posisi untuk mempertimbangkan pengoptimalan kinerja NYATA seperti GDNative atau modul. Saya juga tidak dapat membayangkan mengapa addon mana pun memiliki grafik ketergantungan yang dalam. Satu-satunya alasan saya dapat melihat sebuah addon memiliki ketergantungan pada yang lain adalah jika ia memperluasnya dalam beberapa cara: SweetFpsController -> SweetFpsController w/ flying . Dalam hal ini saya akan mengatakan terserah pada dua proyek atau penggunanya untuk mendamaikan kopling mereka daripada memberikan tanggung jawab kepada mesin.

@Two-Tone jika plugin A membutuhkan versi 1 dari X dan plugin B membutuhkan versi 2 dari X, saya akan mengatakan Godot tidak boleh mencoba untuk memperbaikinya secara ajaib. Berikut adalah solusi sederhana untuk ini:

• Biasanya, versi 2 dari X harus kompatibel dengan versi 1, dan begitulah seharusnya agar tetap sederhana (ingat ketika saya menyebutkan pola pikir saat mengembangkan plugin).
• Jika Anda tidak dapat menggunakan X versi terbaru, tunggu plugin A untuk mendukungnya dan unduh versi sebelumnya (kami memerlukan API asetlib untuk menangani mendapatkan versi yang berbeda, bukan hanya yang terbaru, yang seharusnya tidak sulit dilakukan). Ini seperti mod, tidak harus sempurna.
• Pembuat plugin X mengunggahnya sebagai plugin yang berbeda (karena API merusak kompatibilitas), seperti yang kami lakukan ketika Godot 3 keluar. Jadi Anda akan memiliki dua kali plugin yang sama, tetapi tidak apa-apa karena mereka terlalu berbeda untuk menjadi yang benar-benar sama, dan hal-hal yang bergantung padanya juga akan berfungsi. Itu bahkan bisa berupa penggantian nama folder oleh pengembang plugin, bahkan tidak perlu memiliki dua entri aset lib.

Dalam skenario terburuk, Anda harus membuatnya bekerja secara manual (dan kompatibilitas PR dengan pembuat plugin pada akhirnya).

Jika bukan ini, itu akan melibatkan dua versi dengan jalur berbeda yang diinstal setiap kali (sekrup semua referensi di setiap pembaruan), atau perubahan inti ditambahkan ke mesin untuk mengubah cara kerja jalur (rumit).
Saya pikir jika kita bisa mendapatkan manajemen ketergantungan sederhana , itu sudah cukup bagus, karena pada dasarnya akan menggunakan fungsionalitas dan struktur yang sudah dimiliki Godot (jadi akan sangat mudah untuk diterapkan juga), dan melakukan hal-hal otomatis yang dimiliki pengguna saat ini untuk melakukan secara manual anyways.

Saya tidak menganggap manajemen ketergantungan sebagai hal yang harus selalu berfungsi dan menjadi tanggung jawab seluruh mesin (seperti npm), karena itu akan banyak pekerjaan. Saya menganggapnya terutama sebagai kemudahan untuk hal-hal yang saat ini harus Anda lakukan dengan fungsionalitas yang ada, dan pembuat plugin dapat merilis pekerjaan mereka berdasarkan sistem sederhana tersebut.
Jika seseorang berhasil mengimplementasikan dengan baik sistem yang lebih jauh dari ini, maka itu bisa dilakukan nanti, karena apa yang saya jelaskan di atas dapat diterapkan sebelumnya dan sebagian besar merupakan perbaikan sederhana untuk asetlib dan editor saja.

@Zylann Bagaimana opsi-opsi itu lebih baik dari yang saya sarankan? Dan tidak ada yang ajaib tentang mencari dan menambahkan teks ke string tertentu.

Opsi 1 memaksa pengembang mencoba dan memastikan pembaruan versi mereka tidak merusak plugin lain yang bergantung padanya, yang menambahkan banyak pekerjaan ekstra pada mereka. Siapa yang ingin mengembangkan plugin untuk hal seperti itu?

Opsi 2 memaksa pengguna untuk tidak menggunakan plugin yang mereka inginkan karena mereka harus menunggu hingga plugin diperbarui, jika masih aktif dikembangkan, atau tidak menggunakannya sama sekali.

Opsi 3 sekali lagi mempersulit para pengembang plugin.

Dua versi dengan jalur yang berbeda bukanlah masalah yang sulit. Jika mereka pernah memperbarui, periksa untuk melihat paket instalasi apa yang memilikinya sebagai ketergantungan, jalankan kembali pencarian dan ganti (dengan mempertimbangkan nomor versi lama) pada semua skrip untuk paket tersebut, lalu akhirnya buka paket versi baru.

Saya merasa orang-orang mencoba membuat ini menjadi lebih rumit daripada yang seharusnya.

Manajemen ketergantungan yang tepat dan penghindaran konflik adalah masalah yang penting dan sulit. Itu sedang banyak dibahas karena itu

@Two-Tone Yang saya maksud adalah bahwa Anda berpikir terlalu keras tentang masalah ini bahkan untuk itu menjadi masalah yang sulit. Banyak percakapan (termasuk balasan saya, memang, jadi mohon maafkan saya karena ini akan terdengar munafik) adalah tentang apa yang salah dengan ide-ide yang disajikan, bukan tentang apa yang dapat dilakukan untuk mengubahnya dan menjadikannya lebih baik. rencana. Ide-ide yang disarankan tidak hanya memiliki kekurangan, bukan? Sepertinya semua orang menginginkan cara mereka dan hanya dengan cara mereka sendiri, yang tidak membantu apa-apa.

Mencoba untuk mendorong ini tanpa memikirkan semua masalah yang ditimbulkan oleh ketergantungan akan menjadi ide yang sangat buruk dan hanya menyebabkan lebih banyak masalah. Ini adalah masalah yang sulit dan akan memakan waktu.

Saya menyarankan untuk memunculkan beberapa ide sederhana dengan implikasi bahwa kita akan menyelesaikannya dan kemudian memutuskan begitu kita merasa memiliki sistem yang baik. Saya tidak berpikir saya harus secara eksplisit menunjukkan hal itu, tetapi begitulah.

Saya agak kesal dengan berapa lama percakapan ini berlangsung tanpa kemajuan. Dengan serius.

Dua versi dengan jalur yang berbeda bukanlah masalah yang sulit

Itu saja tidak, mungkin. Tetapi memiliki dua versi plugin yang sama pada waktu tertentu di Godot menyiratkan hal-hal lain yang membingungkan untuk dipecahkan.

• Jalur Anda tidak lagi seperti yang Anda pikirkan / perubahan perlu dilakukan pada inti, yang sebagian besar menjadi perhatian pengembang inti
• Jika plugin memperlihatkan jenis khusus, yang mana yang ditampilkan editor?
• Jika pluginnya C#, bagaimana Anda mengkompilasinya tanpa bertentangan dengan salinan lain?
• Jika plugin mendaftarkan pemuatan otomatis, bagaimana Anda membedakannya?
• Jika pengguna membuat data yang menggunakan plugin, mana yang akan digunakan?
• Yang mana yang akan menampilkan UI di editor?

Saya pikir sebelum kita bahkan dapat menemukan solusi sederhana untuk solusi yang sesuai dengan mesin (dan mungkin ada lebih banyak lagi yang tidak saya pikirkan), kita sudah dapat meningkatkan hal-hal yang ada di editor dan aset lib tanpa merusak kompatibilitas atau memperkenalkan perubahan inti.

Memberi +1 pada semua yang ada di utas ini - memperluas modul plugin dan meningkatkan penggunaan aset lib adalah caranya

Setelah mencoba dan mempelajari Unity, saya sekarang memiliki gagasan yang lebih jelas tentang seperti apa seharusnya ini.

Pertama adalah Unity sekarang memiliki 'Pengelola Paket' yang mereka gunakan untuk memungkinkan pengguna memilih komponen mesin mana yang ingin mereka instal/hapus. Sepertinya mereka juga dapat menggunakan ini untuk Toko Aset di masa mendatang.

Hal seperti ini akan sangat membantu Godot untuk bisa “mengurangi bloat” sekaligus memiliki “official addons”. Unity masih sangat membengkak bahkan dengan Package Manager mereka sementara jika Godot memilikinya, itu bisa menjadi lebih kecil. Metode distribusi "satu exe" mungkin harus digunakan.

Juga, "modul" normal mungkin harus dibangun sebagai perpustakaan bersama (file dll/.so) sehingga mereka dapat dipilih untuk diinstal/dihapus di manajer paket.

Proyek dan paket harus memiliki file manifes yang mencantumkan paket yang bergantung padanya dan Godot / manajer paket akan memastikan bahwa paket yang diperlukan diinstal.

Sebuah registri publik dari paket akan dibutuhkan.

Ini akan memungkinkan komunitas untuk dengan mudah memperluas kemampuan Godot dan dengan mudah membangun karya masing-masing. Saya pikir itu akan banyak mendorong pengembangan masyarakat.

Tidak setuju dengan manfaat keseluruhan dari pindah ke pendekatan Package Manager, saya belum memutuskan hal itu, tetapi saya ingin menunjukkan bahwa itu juga memiliki kelemahan - satu executable tunggal dapat jauh lebih terintegrasi dan baik- diuji, setidaknya lebih mudah.

Dengan manajer Paket, permukaan pengujian tumbuh secara eksponensial untuk setiap plugin dan versi. Ini tidak terlalu buruk jika sebagian besar plugin adalah tambahan kecil (seperti saat ini di AssetLib) tidak mengaitkan terlalu dalam ke inti mesin, tetapi dengan cepat menjadi demikian jika Anda membagi bagian inti mesin.

Unity sudah mengalami masalah, crash, dan masalah kompatibilitas dengan versi berbeda dari paket mereka, editor mereka, atau dengan memiliki beberapa kombinasi paket tertentu yang diinstal (atau tidak diinstal), atau bahkan dengan urutan penginstalannya.

Ini banyak tambahan kompleksitas yang perlu dikelola dengan baik, jangan sampai kita berakhir dalam ketergantungan neraka :)

Mengenai neraka ketergantungan, mengapa tidak mengambil halaman dari sesuatu seperti AppImage dan mencoba menghindari masalah ketergantungan dengan membuat distributor plugin bertanggung jawab untuk mengelola dependensi aset/file? Begini cara saya melihat masalah ini...

Plug-in harus (idealnya) menjadi elemen mandiri baik logika (editor kustom, node kustom, perpustakaan yang terhubung secara dinamis) atau aset (model, bahan, font, tekstur, dll) yang harus memiliki set dependensi mereka sendiri. Mencoba mencari tahu dependensi bersama adalah teka-teki yang, meskipun orang mungkin menyukainya, itu berarti lebih banyak upaya untuk mempertahankannya. Jika Anda benar-benar mengizinkan dependensi bersama, Anda harus mendekati masalah ini mirip dengan runtime Steam dan memelihara banyak perpustakaan, plugin, dan aset yang berbeda sebagai paket unik mereka sendiri. Anda juga perlu menyimpan beberapa paket yang sama di server untuk beberapa versi -- ini akan menjadi mimpi buruk pemeliharaan dan tidak mengherankan bahwa distro linux modern sedikit banyak bergerak menjauh dari manajer paket.

Sebuah plugin pada dasarnya bisa menjadi arsip tar tunggal dari semua elemen yang diperlukan agar plugin itu berfungsi secara terpisah. Mereka harus bekerja secara asli sendiri dengan semua dependensi yang diarsipkan di dalamnya juga. Ketika godot melihat file ini, ia memeriksa file manifes di dalam root folder yang diarsipkan. Manifes ini dapat berisi info dasar (nama, deskripsi, versi godot, ikon, penulis) tetapi juga harus berisi hal-hal seperti: update-info (tautan untuk mengunduh versi terbaru, dikelola oleh pengembang plugin) yang dapat digunakan godot untuk memperbarui secara otomatis plugin (dengan izin pengguna), project_website (tautan ke repositori atau situs web untuk memungkinkan pengguna menemukan sumber paket dengan cepat), dan class_names (daftar kelas dalam addon ini yang dapat diperpanjang, digunakan untuk skrip.) Bisa juga menunjuk ke add-on yang digunakannya sebagai dependensi menggunakan jalur relatif ke file plugin internal.

Jika kami mengizinkan plugin di dalam plugin, maka masalah ketergantungan (kurang lebih) akan terpecahkan. Versi yang berbeda dari perpustakaan yang sama akan berada di jalur direktori yang berbeda dan dapat diperlakukan sebagai 'jalur' yang berbeda pada garpu yang diberikan. Masalah dengan sistem ini, tentu saja, adalah bahwa Anda akhirnya memiliki banyak informasi duplikat pada disk yang diberikan. Namun, saat mengemas game, godot idealnya dapat menelusuri semua direktori plugin dan menggabungkan referensi file yang cocok melalui checksum (ini dapat menyertakan struktur file yang diwakili tar?). Dengan cara ini, jika dua file identik, godot akan mengoptimalkan biner keluaran akhirnya dengan menggabungkan referensi ke satu file.

Saya yakin ini solusi yang terlalu naif untuk masalah yang rumit ini, tetapi saya baru-baru ini memikirkan tentang sistem plugin karena patch font kustom saya. Saya pikir pengalaman pengguna terbaik adalah di mana mereka tidak perlu khawatir tentang dependensi, dan pengembang adalah orang yang harus peduli dengan pengelolaan dependensi mereka sendiri. Ini memudahkan pengguna untuk mengelola: sebuah proyek dapat memiliki add-on mereka direpresentasikan sebagai satu file di dok sistem file, Anda dapat mengklik kanan dan mendapatkan opsi tambahan ( extract files (untuk pengembangan), update plugin (untuk pembaruan yang mudah), buka situs web ( for easy community organization )) dan juga kelas referensi dalam 'wadah' yang diberikan ( extends "[path-to-addon-tar]://ClassName" )

Hanya 2 sen saya tentang masalah ini, saya yakin ada beberapa kekurangan dengan cara saya memikirkannya juga, tetapi itu bisa menjadi solusi yang menarik dan juga menjadi cara yang layak untuk mengurangi kebutuhan pemeliharaan untuk tim Godot.

Hanya 2 sen berdasarkan 2 sen sebelumnya (apakah ini membuatnya menjadi 4 mil?):
Saya kira arsip .tar akan sedikit asing bagi sebagian besar pengguna (ahem, pengguna windows) jadi mungkin lebih baik menggunakan arsip .zip , karena mereka memiliki dukungan yang lebih luas.

Meskipun demikian, bagaimana dengan mendistribusikan plugin dalam format .pck Godot sendiri? Saya memang memiliki beberapa kontra (seperti tidak dikenali oleh sebagian besar aplikasi), tetapi itu mungkin kesempatan untuk membuatnya lebih standar dan digunakan.

Saya kira arsip .tar akan sedikit asing bagi sebagian besar pengguna (ahem, pengguna windows) jadi mungkin lebih baik menggunakan arsip .zip, karena mereka memiliki dukungan yang lebih luas.

Meskipun demikian, bagaimana dengan mendistribusikan plugin dalam format .pck milik Godot? Saya memang memiliki beberapa kontra (seperti tidak dikenali oleh sebagian besar aplikasi), tetapi itu mungkin kesempatan untuk membuatnya lebih standar dan digunakan.

Tentu, maksud saya .tar sebagai contoh tipe arsip paket generik. Itu bisa dan mungkin harus menggunakan format .pck godot.

Mengapa tidak menggunakan ZIP karena menawarkan kompresi dan merupakan format standar?

@Calino saya setuju. Jika kami mengamanatkan bahwa file .pck harus digunakan, maka orang harus menggunakan Godot Engine untuk mengemas barang-barang daripada hanya menggunakan alat pengepakan pilihan mereka untuk menggabungkan plugin mereka untuk digunakan. GitHub juga mengunduh repositori sebagai file .zip dan menampung koleksi plugin Godot terbesar sejauh ini.

Saya setuju di sini. Saya tidak berpikir jenis file lain perlu dibuat. File zip tampaknya bekerja dengan sangat baik, dan orang-orang memiliki opsi untuk menginstal menggunakan antarmuka Godot melalui pustaka aset, atau mereka dapat mengunduh sendiri secara manual. file .pck tidak mengizinkan pilihan itu.

Di dunia ideal saya, saya ingin memiliki dua tombol unduh di https://godotengine.org/download :

• Satu unduhan minimum ramping yang memenuhi tiga persyaratan reduz, dan
• Satu unduhan mengasapi dengan semua plugin yang disetujui dan dan dipelihara secara teratur yang telah melampaui beberapa kontrol kualitas, jadi saya tahu API mereka berfungsi setidaknya sama baiknya dengan inti sebagai API dari versi minimum.

Bahkan lebih ideal:
Pilih dan campur. Setelah mengunduh minimum, saya dapat memilih versi minimum + Plugin "Tema". Yang merupakan kumpulan plugin umum yang diperlukan untuk kasus penggunaan umum. (jadi misalnya: 2DPixelart, 3D FirstPersonShooter, 3D ThirdPerson, RTS, RPG, game 2.5D, 2DCutout, Rougelike, ManagementSim, Sidescroller, Eventpackage, Shaderpackage, Scriptpackage, Assetpackace, dll). Jadi ketika saya memulai mesin, plugin esensial sudah diinstal dan siap digunakan dan saya tahu mereka berfungsi karena telah disetujui.
Pengguna yang lebih mahir dapat menghapus plugin individu dalam koleksi Tema tersebut jika mereka tahu bahwa mereka tidak membutuhkannya, atau menggabungkan dua atau lebih Tema Plugin, atau menambahkan plugin tunggal tambahan ke Tema dari kumpulan plugin yang disetujui untuk membuat paket khusus.

Idealnya, hasilnya adalah https://godotengine.org/download membuat dari pilihan tersebut _satu tautan unduhan dengan cepat_.

Mengapa? Karena ini akan sangat menghemat waktu dan jaminan kualitas untuk orang yang bekerja dalam tim atau kelompok, untuk pendidik dan guru di sekolah yang harus menggunakan banyak komputer, untuk orang yang mengikuti tutorial dan menginginkan konfigurasi yang sama dengan tutor, untuk individu yang senang ada satu plugin resmi yang disetujui oleh tim pengembang untuk sesuatu yang umum digunakan, tetapi tidak oleh semua orang, jadi tidak perlu menggali Github dan Reddit selama berhari-hari untuk menemukan apa yang mereka butuhkan, tidak tahu mana yang paling didukung pilihan dari 6 yang mereka temukan.

Unduhan minimal sekali klik harus tetap ada bagi mereka yang membutuhkan ukuran kecil, serta unduhan fitur maksimal yang tidak peduli dengan ukuran tetapi menginginkan fitur maksimal untuk melihat apa yang dapat dilakukan mesin.

Solusi yang lebih sederhana adalah dengan meminta untuk menginstal plugin [resmi saja?] tambahan saat menjalankan editor untuk pertama kalinya. Saat ini kami memiliki opsi untuk membuka AssetLib jika daftar proyek kosong; mengapa tidak memiliki popup dialog untuk menginstal plugin resmi jika menjalankan Godot untuk pertama kalinya?

Menutup mendukung https://github.com/godotengine/godot-proposals/issues/142 , https://github.com/godotengine/godot-proposals/issues/577 dan https://github.com/godotengine/ godot-proposals/issues/607 , karena proposal fitur sekarang dilacak di repositori proposal Godot.

Sunting dari aaronfranke: Lihat juga https://github.com/godotengine/godot-proposals/issues/554