Skeleton Walkthrough

Bagian ini menguraikan struktur fundamental dari integrasi LightScript, mencakup persyaratan teknis utama, contoh dunia nyata, konvensi penamaan, dan tips efisiensi. Ini memandu melalui loop update, perilaku meter, logika pemicuan efek, dan menyoroti jebakan umum. Baik Anda sedang debugging, membangun dari awal, atau memelihara kode orang lain, panduan ini menekankan kejelasan, stabilitas, dan performa sebagai standar utama integrasi berkualitas tinggi.

Tata Letak Dasar

Bagian ini memberikan gambaran singkat tentang pengaturan LightScript dari sudut pandang pemeliharaan, dengan fokus pada di mana masalah biasanya terjadi dan cara menemukan dan memperbaiki bug. Kita akan mulai dengan panduan singkat tentang struktur LightScript yang ideal untuk membiasakan Anda dengan kode, kemudian membahas pemecahan masalah, dan diakhiri dengan FAQ.

Kerangka dasar memerlukan <head>, <body>, dan <script>. Semua deklarasi meter dan kontrol pengguna masuk ke dalam <head>. Semua deklarasi canvas termasuk dalam <body>. Semua yang lain harus ditempatkan di bagian <script>.

<head>

<head> adalah salah satu bagian yang paling kritis dan kompleks dari LightScript mana pun. Kontrol pengguna atau meter yang rusak di sini dapat menyebabkan crash loop atau menonaktifkan dirinya sendiri dan meter yang dideklarasikan setelahnya.

Saat membuat meter, Anda perlu memastikan:

Sintaks yang sempurna (untuk menghindari crash dan meter yang rusak)
Tidak ada nama meter duplikat (duplikat akan ditimpa)
Tidak ada meter yang melampaui batas layar (menyebabkan crash dan error)
Tidak ada opsi yang hilang atau berlebih dalam meter (menyebabkan crash)
Semua meter menyertakan penyesuaian resolusi (memastikan perilaku yang konsisten)

Mengenai resolusi, rasio aspek yang paling umum adalah:

16:9 (3840x2160, 2560x1440, 1920x1080, 1600x900, 1366x768, 1360x768, 1280x720)
16:10 (2560x1600, 1920x1200, 1680x1050, 1440x900, 1280x800)
21:9 (5120x2160, 3440x1440)

Secara default, kita menggunakan resolusi 2560x1440.

Semua LightScript harus mendukung rasio aspek 16:9, 16:10, dan 21:9. Meskipun 4:3 tidak mewakili sebagian besar basis pengguna kami, hal ini tetap harus dipertimbangkan untuk kompatibilitas di masa mendatang.

Berikut contoh struktur untuk meter dengan beberapa pengaturan resolusi:

Lokasi dan ukuran default meter Anda berlaku untuk setiap resolusi lain dalam rasio aspek yang sama. Misalnya, jika Anda awalnya menyesuaikan meter agar bekerja dengan 1600x900, meter tersebut seharusnya berfungsi dengan baik di semua resolusi 16:9 lainnya. Namun, ada pengecualian. Fortnite memiliki beberapa posisi penempatan meter yang berbeda bahkan dalam rasio aspek yang sama, dan beberapa rasio aspek itu sendiri bisa menyesatkan. Misalnya, 1366x768, resolusi umum di seluruh dunia, sering terdaftar sebagai 16:9 tetapi sebenarnya bukan rasio 16:9 yang sebenarnya, yang tidak jarang terjadi. Demikian pula, rasio ultrawide seperti 21:9 jarang sesuai dengan dimensi nominalnya. Dalam pengalaman saya sebagai pengembang integrasi, saya tidak pernah menemukan resolusi 21:9 yang tepat meskipun berlabel demikian. Karena itu, setiap resolusi ultrawide harus dibuat, diuji, dan dikonfigurasi secara individual.

Semua penyesuaian harus ditempatkan antara tag pembuka <meta> dan penutup </meta>; jika tidak, penyesuaian tersebut tidak akan berfungsi. Jika meter default Anda didasarkan pada 16:9 dan berperilaku konsisten di seluruh resolusi tersebut, Anda tidak perlu menambahkan penyesuaian untuk resolusi 16:9 lainnya. Namun, Anda harus menambahkan entri untuk setiap resolusi dalam rasio aspek lain (seperti 16:10 dan 21:9), bahkan jika rasionya konsisten.

Terakhir, setiap meter kecuali meter OCR kami memerlukan rentang HSL untuk dipicu. Rentang ini bisa diperumit oleh faktor-faktor seperti:

Elemen UI transparan
Gradien di area warna
Efek warping layar
Pembukaan menu dalam game
Penyesuaian UI per resolusi
Penggunaan controller vs. keyboard
Perekaman video, yang dapat menimbulkan kesalahan piksel terkait kompresi

Instruksi dasar tentang HSL dan koordinat ternormalisasi dibahas dalam dokumen developer kami dan tidak akan diulang di sini. Pengujian meter ini akan dibahas di bagian “Mengidentifikasi Masalah”, tetapi penting untuk ditekankan: jumlah pengujian yang diperlukan untuk memverifikasi semua meter dengan sempurna dihitung sebagai (jumlah meter) × (jumlah penyesuaian resolusi) × (jumlah mode game) × (jumlah karakter yang dapat dimainkan) × (durasi rata-rata satu game). Ini dapat dengan mudah bertambah hingga berjam-jam verifikasi per game, terutama jika mode latihan atau solusi lain tidak tersedia.

JAGA METER ANDA TETAP EFISIEN, standar kami adalah kesempurnaan.

<body>

Tag <body> adalah tempat elemen canvas yang sebenarnya dideklarasikan. Tampilannya harus selalu kurang lebih seperti contoh berikut. id canvas yang sebenarnya dapat diubah jika Anda mau, tetapi pastikan Anda mengambilnya dengan benar dalam script.

Hemat waktu Anda dengan menyalin dan menempelkan ini.

<script>

Empat hal harus terjadi di dalam tag ini dalam setiap integrasi:

Canvas diambil dan digunakan untuk membuat konteks 2D kita.
Loop update awal menetapkan nilai meter, kemudian memanggil dirinya sendiri tanpa batas untuk mempertahankannya.
Loop update menjaga variabel kontrol pengguna tetap diperbarui.
Meter menjalankan fungsi callback mereka saat stabil.

Prosedur Umum

Kita telah menyiapkan kerangka kode dasar. Langkah berikutnya adalah menelusuri loop eksekusi yang memicu efek dari awal hingga akhir.

UI video game menampilkan informasi dalam bentuk bar berwarna, tombol, kotak teks, dll. SignalRGB menangkap data ini beberapa kali per detik, tetapi kecepatan tangkapan yang sebenarnya sangat bergantung pada efisiensi kode Anda. Untuk memperjelas, satu loop atau variabel yang tidak dideklarasikan dapat merusak seluruh script Anda, dan bahkan membuat SignalRGB crash. Lebih buruk lagi, mudah untuk menulis kode yang secara teknis berfungsi, tetapi sangat tidak efisien sehingga hanya menangkap info pada 1-2 FPS.
Setiap meter yang dideklarasikan dalam <head> harus sekecil dan seefisien mungkin untuk mengurangi overhead. Lakukan perhitungan Anda lebih awal dan sering; meter yang mengambil 25% layar tidak pernah efisien. Dengan meter OCR, tangkap huruf individual alih-alih kata-kata lengkap. Untuk health dan mana bar, pantau hanya segmen yang penting. JAGA METER ANDA SEKECIL MUNGKIN.
Meter menangkap informasi yang disegarkan dengan setiap loop.
Sebelumnya, kita membahas definisi kelas Meter, yang menyimpan data meter dan memicu callback ketika array info menjadi stabil. Di bagian atas script Anda, deklarasikan semua Meter dalam satu blok. Anda dapat mengaturnya atau menyusunnya secara alfabetis; jangan mengubur mereka di seluruh ribuan baris. Pada akhirnya Anda perlu menyesuaikan nilai stabilitas, dan membuang waktu mencoba mengingat di mana Anda menempatkannya.
Di dalam fungsi update, meter-meter ini akan menerima nilai dari logika pembacaan layar setiap loop. Logika internal mereka mengevaluasi stabilitas dan, saat stabil, memicu fungsi callback terkait mereka.
Fungsi callback ini harus dideklarasikan dalam script Anda tetapi di luar fungsi update. Di dalamnya, periksa status nilai Meter Anda (value, decreased, increased, diff) dan gunakan itu untuk menentukan apakah akan memainkan animasi efek. Menyusun kode Anda dengan cara ini, daripada menempatkan semuanya langsung di dalam loop update, memungkinkan kita membangun integrasi yang skalabel.

Contoh Dunia Nyata

Sekarang Anda memiliki gambaran umum, saya akan dengan cepat menelusuri contoh loop dunia nyata.

Saya sedang bermain game League of Legends, yang mengelilingi skill yang tersedia dengan sorotan kuning terang.
Setiap loop, meter skill tertentu mengambil warna ini sebagai nilai “1” karena sepenuhnya lolos rentang HSL meter.
“1” ini diteruskan ke instansi Meter yang terlampir pada meter pembacaan layar dan dimasukkan ke dalam array info Meter tersebut.
Jika setiap nilai dalam array tersebut adalah “1”, dianggap stabil, dan akan mengaktifkan fungsi callback efek yang terlampir. Fungsi callback ini juga akan diaktifkan jika setiap nilai adalah “0”, atau “.1” misalnya; yang dipedulikan Meter hanyalah stabilitas. Satu catatan penting di sini adalah bahwa fungsi callback tidak akan terus-menerus diaktifkan jika Meter terus stabil pada nilai yang sama – hanya stabilitas dengan nilai BARU yang akan mengaktifkan callback.
Setelah fungsi callback dieksekusi, kita sampai pada beberapa pemeriksaan kondisional – dalam kasus ini, yang harus kita lakukan adalah memeriksa apakah Meter.value adalah “0”, menunjukkan skill telah digunakan.
Karena nilai Meter adalah “1”, kita gagal pemeriksaan ini dan tidak akan memainkan efek skill.
Beberapa detik kemudian, saya mengaktifkan skill dan sorotan kuning di sekitar tombol menghilang.
Nilai meter baru adalah 0, yang diteruskan ke kelas Meter-nya.
Setelah stabilitas tercapai, callback mengaktifkan dan kondisional kita lolos, memainkan efek skill. Latensi sepenuhnya bergantung pada panjang array Meter, yang Anda tetapkan saat deklarasinya. Panjang lebih berarti latensi lebih dan pemicuan salah lebih sedikit, jadi pastikan untuk menguji hingga Anda menemukan keseimbangan yang baik.

Konvensi Penamaan

Meter pembacaan layar harus memiliki nama yang sederhana, jelas, dan deskriptif, selalu dimulai dengan huruf kecil. Menamakan meter health bar “healthBar” sangat baik. Menamakan dua meter “healthBarRed” dan “healthBarGreen” saat mereka melacak warna berbeda di area yang sama juga bagus. Tetapi menamakan meter kecil yang hanya muncul selama efek ultimate satu hero seperti “hrO21_yes” hanya akan membawa penderitaan bagi siapa pun yang mencoba memperbaiki kode Anda. Mencari tahu apa yang dilacak oleh meter kecil yang diberi nama buruk dapat secara harfiah membutuhkan satu jam menatap piksel individual jika Anda tidak beruntung, jadi jangan lakukan ini.

Instansi kelas Meter harus dikapitalisasi dan diakhiri dengan kata Meter. Contoh seperti “Q_Meter”, “TookDamageMeter”, dan “TowerDestroyedMeter” semuanya baik-baik saja. Ini harus jelas dapat dibedakan dari meter yang dideklarasikan di bagian <head>.

Fungsi efek juga harus diberi nama sesederhana dan sedeskriptif mungkin. Beberapa game memiliki ratusan fungsi ini; yang lain mungkin memiliki kurang dari sepuluh. Jika beberapa hero memiliki skill unik, sertakan nama hero sebagai awalan, seperti “SonaQ”, “ChamberE”, atau “AshUlt”. Di League of Legends, misalnya, ada fungsi seperti “DragonEffect”, “TowerEffect”, dan “Q_Effects”, yang berisi beberapa kondisional dan digunakan oleh beberapa meter. Jadi, jenis penamaan ini juga membantu optimasi untuk skala.

Jangan salah mengeja kata. Jika Anda tidak yakin cara mengeja sesuatu, cari tahu. Nama harus jelas dan dapat dibaca, terlepas dari siapa yang mengerjakan kode atau berapa banyak waktu yang telah berlalu. Mengatur nama secara alfabetis membantu pencarian cepat, terutama jika Anda akan sering mengedit bagian tersebut. Meskipun tingkat organisasi ini tidak diperlukan agar kode berjalan, ini membuat perbedaan besar bagi pengembang pemeliharaan kami.