مرکزی مواد پر جائیں
اے آئی ٹیوٹوریلز

Astra اور JEV مائن کرافٹ ایجنٹ چلائیں اور تصدیق کریں

Minecraft Java 1.16.5 کے لیے Astra اور JEV ایجنٹ کو انسٹال، ترتیب، لانچ، ٹیسٹ، ریکارڈ اور تصدیق کرنے کا طریقہ سیکھیں۔ یہ گائیڈ پلانر-ایکشن آرکیٹیکچر، اسناد کے انتظام، نئی دنیا کی تیاری، مقامی کلائنٹ کے ورک فلو، ثبوت کی فائلوں اور جدید جنگی و ریکارڈنگ کے امور کی وضاحت کرتی ہے۔

Astra اور JEV مائن کرافٹ ایجنٹ چلائیں اور تصدیق کریں

پروجیکٹ کیا کرتا ہے

Astra اور JEV کا Minecraft ایجنٹ ساختہ گیم مشاہدات اور محدود کھلاڑیانہ اقدامات کے ذریعے پہلے سے متعین Minecraft Java 1.16.5 روٹ مکمل کرتا ہے۔ GPT-6 Astra، یا اختیاری طور پر GPT-5.6 Sol، مقاصد، مطلوبہ اشیا اور سفر کے راستے کے نقاط کی منصوبہ بندی کرتا ہے۔ اس کے بعد JEV دستیاب کارروائی منتخب کرتا ہے، جبکہ Mineflayer حرکت، راستہ تلاش کرنے اور معمول کے گیم پروٹوکول تعاملات انجام دیتا ہے۔

یہ صرف اسکرین شاٹ پر مبنی کنٹرول نہیں ہے اور نہ ہی انفرادی کی بورڈ پریسز کی نقل کرتا ہے۔ ماڈلز کو ساختہ حالت موصول ہوتی ہے، جس میں لوڈ شدہ حصوں کے بلاکس اور معلوم seed کے لیے فراہم کردہ نقاط شامل ہیں۔ دستیاب کارروائیوں میں سفر کرنا، ایک بلاک کھودنا، گرنے والی اشیا جمع کرنا، crafting، چیسٹ کھولنا، کھانا، سونا اور جنگی تعاملات شامل ہیں۔

تازہ ترین تصدیق شدہ رن، nether-final-08، 8 منٹ 43.300 سیکنڈ میں مکمل ہوئی۔ یہ Peaceful مشکل پر ایک نئی Survival دنیا میں خالی inventory کے ساتھ شروع ہوئی، Nether سے گزری، پہلی بار اترنے پر چھ bed دھماکوں کے ذریعے Ender Dragon کو ہلاک کیا، اور مکمل صحت اور بغیر کسی موت کے exit portal میں داخل ہوئی۔ اس رن میں 131 JEV فیصلے اور 35 Astra کالز استعمال ہوئیں۔

یہ پروجیکٹ سرکاری vanilla سرور استعمال کرتا ہے اور منتخب کارروائیاں معمول کے player protocol کے ذریعے بھیجتا ہے۔ اس کا Java dragon sensor صرف پڑھنے کے لیے ہے: یہ ڈریگن کے سر کی درست پوزیشن بتاتا ہے، مگر اشیا نہیں دیتا، entities کو حرکت نہیں دیتا، صحت تبدیل نہیں کرتا اور گیم کے قواعد میں ردوبدل نہیں کرتا۔

اہم خصوصیات

  • ماڈلز کے الگ کردار: Astra یا Sol موجودہ مقصد کی منصوبہ بندی کرتا ہے، جبکہ JEV موجودہ مشاہدے سے ایک محدود کارروائی منتخب کرتا ہے۔
  • Minecraft کے معمول کے تعاملات: Mineflayer حرکت، راستہ تلاش کرنے، بلاک تعاملات، crafting، inventory کارروائیوں اور پروٹوکول رابطے کو سنبھالتا ہے۔
  • Nether کی مدد سے روٹ: مقررہ روٹ End کی لڑائی سے پہلے سفر کے مختصر راستے کے طور پر Nether استعمال کرتا ہے۔
  • صرف پڑھنے کے لیے dragon observation: ایک مقامی Java sensor درست bed timing کے لیے ڈریگن کے سر کی پوزیشن بتاتا ہے، entity کی حالت میں کوئی تبدیلی کیے بغیر۔
  • Native recording: ایک مخفی سرکاری Minecraft Java 1.16.5 کلائنٹ native models، textures، animations، inventory screens، health، hunger، air، hotbar state، ہاتھ میں پکڑی اشیا اور dragon health رینڈر کرتا ہے۔
  • کنٹرول شدہ کیمرا حرکت: کیمرا موڑ ہر axis پر 240 ڈگری فی سیکنڈ تک محدود ہیں، جبکہ acceleration 960 ڈگری فی سیکنڈ مربع ہے۔
  • ساختہ شواہد: JSONL event logs، status files، victory evidence، video manifests اور world-state checks بعد کی تصدیق میں مدد دیتے ہیں۔
  • خودکار ٹیسٹس: repository میں completion events، native packets، action policy اور pathfinder cancellation کے لیے checks شامل ہیں۔

Architecture اور ماڈل configuration

ڈیفالٹ planner model openai/gpt-6-astra ہے، جسے /api/v1/chat/completions کے ذریعے کال کیا جاتا ہے۔ آپ PLANNER_MODEL environment variable کے ذریعے openai/gpt-5.6-sol منتخب کر سکتے ہیں۔ JEV /api/alpha/decisions کے ذریعے typesafe/jev-1.13 استعمال کرتا ہے۔

planner براہِ راست من مانی کارروائیوں کے سلسلے انجام نہیں دیتا۔ یہ موجودہ مقصد، مطلوبہ اشیا اور waypoint متعین کرتا ہے۔ JEV موجودہ ساختہ مشاہدے کا جائزہ لے کر ایک مجاز کارروائی منتخب کرتا ہے۔ یہ علیحدگی انفرادی فیصلوں کو محدود رکھتی ہے، جبکہ مجموعی رن کو ایک طویل منصوبے کے مطابق چلنے دیتی ہے۔

تقاضے اور اہم حدود

لانچ اور native-rendering scripts macOS پر تیار کی گئی تھیں۔ دوسرے operating system پر آپ کو runtime paths، Java locations اور مقامی server settings کے مطابق تبدیلیاں کرنی ہوں گی۔ فراہم کردہ native launch script اپنا مقامی Java 17 runtime استعمال کرتی ہے۔

آپ کو Node.js اور npm، native client scripts کے لیے Python 3، ایک compatible Java runtime، Google Application Default Credentials، OpenRouter key پر مشتمل Google Secret Manager secret تک رسائی اور کافی OpenRouter credit درکار ہے۔ Minecraft binaries، downloaded runtimes، saved worlds، recordings اور credentials کو جان بوجھ کر Git سے خارج رکھا گیا ہے۔

دستاویزی game configuration یہ ہے:

  • Seed: 8398967436125155523
  • Mode: Survival
  • تصدیق شدہ recording کے لیے استعمال ہونے والی difficulty: Peaceful
  • فعال End portal کا مرکز: -1130, 34, 856
  • Main server: 127.0.0.1:25576
  • Status endpoint: http://127.0.0.1:3078
  • ایجنٹ کے زیرِ استعمال مقامی dragon sensor endpoint: http://127.0.0.1:3093
  • Native protocol mirror port: 25578

اس seed میں ایک گاؤں، 21 obsidian والے تین supply chests اور قدرتی طور پر فعال End portal موجود ہے۔ دستاویزی روٹ کے لیے blaze rods درکار نہیں ہیں۔ نقاط کا سروے ایک الگ test world میں کیا گیا تھا، مگر final-run کی حرکت اور placements معمول کے player interactions استعمال کرتی ہیں۔

مرحلہ 1: Node.js dependencies انسٹال کریں

repository root سے project packages انسٹال کریں:

npm install

یہ agent، model relay، route logic، evidence tooling اور tests کے لیے استعمال ہونے والی JavaScript dependencies انسٹال کرتا ہے۔

مرحلہ 2: محفوظ model access configure کریں

ایجنٹ جان بوجھ کر عمومی OPENROUTER_API_KEY environment variable کو نظرانداز کرتا ہے۔ اس کے بجائے model calls key کو Google Secret Manager سے load کرتی ہیں اور اسے صرف process memory میں رکھتی ہیں۔ key کو source files یا run logs میں ظاہر نہیں ہونا چاہیے۔

  1. model-relay.mjs اور models.mjs کھولیں۔
  2. اصل تعیناتی کے Google Cloud پروجیکٹ اور سیکرٹ کے حوالہ جات کو اپنے پروجیکٹ کے حوالہ جات سے تبدیل کریں۔
  3. Google Application Default Credentials کے ذریعے مقامی طور پر تصدیق کریں۔
  4. تصدیق شدہ شناخت کو منتخب کردہ سیکرٹ تک رسائی کی اجازت دیں۔
  5. ریپوزٹری کے ریلے سیٹ اپ کے مطابق ماڈل ریلے شروع کریں۔
  6. ایجنٹ لانچ کرتے وقت ریلے URL مقرر کریں:
MODEL_RELAY=http://127.0.0.1:3099

OpenRouter کی کلید کو سورس کوڈ، شیل اسکرپٹس، ایونٹ لاگز یا رن میٹا ڈیٹا میں پیسٹ نہ کریں۔ پروجیکٹ کو Secret Manager سے کلید حاصل کرنے اور اسے پروسیس میموری میں رکھنے کے لیے ڈیزائن کیا گیا ہے۔

مرحلہ 3: سرور اور ڈریگن آبزرور تیار کریں

مطابقت رکھنے والی vanilla Minecraft Java 1.16.5 سرور JAR کو server/server.jar پر رکھیں۔ README میں درج ہے کہ نصب شدہ Minecraft Java رن ٹائم اس سرور کو چلا سکتا ہے۔

ڈریگن آبزرور observer/DragonObserver.java میں نافذ کیا گیا ہے۔ اسے اس کمانڈ سے بنائیں:

./build-observer.sh

مرکزی سرور اور اس کے صرف پڑھنے والے سینسر کو اس کمانڈ سے شروع کریں:

./start-server.sh

آبزرور سرور کے ڈریگن ٹک میں صرف مقامی مشاہدے کے لیے ایک کال شامل کرتا ہے۔ اسے صرف پڑھنے والا رہنا چاہیے؛ یہ ڈریگن AI یا کسی کھلاڑی یا entity کی حالت تبدیل نہیں کرتا۔

واقعی نئی دنیا بنائیں

نئی رن ڈائریکٹری بنانے سے Minecraft کی دنیا ری سیٹ نہیں ہوتی۔ نئی ریکارڈنگ سے پہلے سرور روکیں اور server/server.properties میں ایسا level-name منتخب کریں جو پہلے استعمال نہ ہوا ہو۔ ترتیب دیا گیا seed تبدیل نہ کریں، پھر سرور دوبارہ شروع کریں۔

رن لاگ ڈائریکٹری کے لیے بھی یہی نیا نام استعمال کریں۔ پچھلی دنیاؤں کو محفوظ رکھیں جب وہ سابقہ رنز کے شواہد کا حصہ ہوں۔

مرحلہ 4: مقامی کلائنٹ انسٹال اور بلڈ کریں

مخفی مقامی کلائنٹ نئی ریکارڈنگز میں استعمال ہونے والی سرکاری Minecraft رینڈرنگ فراہم کرتا ہے۔ اس کے Python-side انحصارات انسٹال کریں اور ڈسپلے اور کیپچر اڈاپٹر بنائیں:

python3 native-client/install.py
./native-client/build.sh

کلائنٹ ایک الگ گیم ڈائریکٹری استعمال کرتا ہے، اس لیے یہ صارف کی عام Minecraft ترتیبات کو اوور رائٹ نہیں کرتا۔ ڈیسک ٹاپ فوکس اور کرسر کنٹرول غیر فعال ہیں، اور کیپچر ڈیسک ٹاپ ریکارڈ کرنے کے بجائے گیم کے فریم بفر سے پڑھتا ہے۔

مرحلہ 5: رن کی ترتیب منجمد کریں

ایک منفرد شناخت کنندہ منتخب کریں، جسے ذیل میں NEW_RUN سے ظاہر کیا گیا ہے۔ ایجنٹ لانچ کرنے سے پہلے رن کو منجمد کریں:

node optimization/nether/freeze-run.mjs NEW_RUN

حتمی راستہ optimization/nether/config.json میں متعین ہے۔ رن منجمد کرنے سے اس کے نتیجے میں بننے والے لاگز اور ریکارڈنگ سے وابستہ ترتیب محفوظ رکھنے میں مدد ملتی ہے۔

مرحلہ 6: ایجنٹ شروع کریں

ایجنٹ کو ریپوزٹری کی جڑ سے لانچ کریں۔ درج ذیل کمانڈ Astra منتخب کرتی ہے، مقامی منظر اور ریکارڈر فعال کرتی ہے، مقامی کلائنٹ کا انتظار کرتی ہے، اور ڈریگن سینسر سے منسلک ہوتی ہے:

PLANNER_MODEL=openai/gpt-6-astra RUN_ID=NEW_RUN \
NATIVE_VIEW=1 WAIT_NATIVE=1 NATIVE_RECORD=1 \
DRAGON_SENSOR_URL=http://127.0.0.1:3093 node nether-agent.mjs

اگر ریلے URL پہلے سے پروسیس کے ماحول میں موجود نہ ہو تو اسے بھی شامل کریں:

MODEL_RELAY=http://127.0.0.1:3099 \
PLANNER_MODEL=openai/gpt-6-astra RUN_ID=NEW_RUN \
NATIVE_VIEW=1 WAIT_NATIVE=1 NATIVE_RECORD=1 \
DRAGON_SENSOR_URL=http://127.0.0.1:3093 node nether-agent.mjs

اس کے بجائے Sol کو پلانر کے طور پر استعمال کرنے کے لیے ماڈل کی قدر تبدیل کریں:

PLANNER_MODEL=openai/gpt-5.6-sol

مرحلہ 7: مخفی Minecraft کلائنٹ لانچ کریں

مقامی پروٹوکول مرر کے پورٹ 25578 پر سننے تک انتظار کریں۔ پھر ایک اور ٹرمینل کھولیں اور چلائیں:

python3 native-client/launch.py

چونکہ WAIT_NATIVE=1 فعال ہے، اس لیے ایجنٹ اپنا پہلا عمل کرنے سے پہلے مخفی کلائنٹ اور ریکارڈر کا انتظار کرتا ہے۔ ریکارڈر exit-portal ایونٹ کے بعد رک جاتا ہے۔

نتیجے میں بننے والا کیپچر 960 × 540 ریزولوشن اور 20 فریم فی سیکنڈ کے لیے، آڈیو کے بغیر، تیار کیا گیا ہے۔ اس میں صحت، بھوک، ہاٹ بار، ہاتھ میں موجود اشیا، انوینٹری اور کرافٹنگ اسکرینز، مقامی اینیمیشنز اور ڈریگن کی صحت دکھائی جا سکتی ہے۔

رن کی نگرانی اور اسے محفوظ طریقے سے روکنا

موجودہ حالت مقامی اسٹیٹس اینڈ پوائنٹ سے دستیاب ہے:

http://127.0.0.1:3078

موجودہ پیش رفت status.json میں بھی لکھی جاتی ہے۔ کسی ایکشن کی حد پر رکنے کی درخواست کرنے کے لیے درج ذیل فائل بنائیں:

runs/NEW_RUN/stop

رن ختم ہونے کے فوراً بعد مقامی کلائنٹ کو ختم نہ کریں۔ ریکارڈنگ کی تکمیل کے مارکر کا انتظار کریں:

runs/NEW_RUN/full-playthrough.mp4.finished.json

اس سے حتمی کیپچر کے نامکمل یا خراب ہونے سے بچنے میں مدد ملتی ہے۔

تیار شدہ شواہد کو سمجھنا

ہر رن اپنے شواہد runs/<run> کے تحت محفوظ کرتا ہے۔ سب سے اہم فائلیں یہ ہیں:

  • events.jsonl: درخواستیں، ماڈل کے جوابات، منتخب کردہ اعمال، گیم کے نتائج اور تکمیل کے ایونٹس۔
  • status.json: رن کی تازہ ترین پیش رفت۔
  • victory.json: صرف اس وقت بنتی ہے جب مطلوبہ ڈریگن موت اور exit-portal کے شواہد موجود ہوں۔
  • full-playthrough.mp4: ریکارڈنگ فعال ہونے پر مقامی ریکارڈنگ۔
  • full-playthrough.mp4.finished.json: اس بات کی تصدیق کہ ریکارڈنگ کی تکمیلی کارروائی مکمل ہو گئی ہے۔

ڈریگن کی موت کا ثبوت kill advancement یا سرور کی رپورٹ کردہ صفر صحت اور ڈریگن کے dying phase کے امتزاج پر مشتمل ہو سکتا ہے۔ یہ فرق اہم ہے کیونکہ بستر سے کیے گئے قتل میں kill advancement شامل نہ ہو سکتی ہے۔ Java 1.16.5 کے لیے exit event میں عددی وجہ 4 استعمال ہوتی ہے۔

درست حتمی جائزے میں صرف victory.json پر انحصار نہیں کرنا چاہیے۔ اسے دنیا کی DragonFight حالت اور ویڈیو کا بھی جائزہ لینا چاہیے۔

خودکار جانچیں چلائیں

تکمیل کے واقعات، مقامی مرر پیکٹس، ایکشن پالیسی، اور پاتھ فائنڈر کی منسوخی جانچنے کے لیے ریپوزٹری کا Node ٹیسٹ سوٹ استعمال کریں:

node --test evidence.test.mjs native-mirror.test.mjs optimization/*.test.mjs optimization/pass-2/policy.test.mjs optimization/nether/*.test.mjs

یہ ٹیسٹس لائیو توثیق کا متبادل نہیں ہیں۔ موومنٹ، کرافٹنگ، کامبیٹ، سرور انٹیگریشن، اور ریکارڈنگ کے لیے اب بھی چلتے ہوئے Minecraft سرور کے خلاف ٹیسٹس درکار ہیں۔

End combat کیسے کام کرتا ہے

end-combat.mjs میں موجود کامبیٹ امپلیمنٹیشن JEV کے انتخاب کے لیے ایک محدود bed attack فراہم کرتی ہے۔ یہ ایک bed رکھتی ہے، اس پر نشانہ باندھتی ہے، مشاہدہ شدہ dragon head کے مقررہ attack window میں داخل ہونے تک انتظار کرتی ہے، اور ایک use command بھیجتی ہے۔

اگر کھلاڑی cover کھو دے یا dragon breath، cover area میں داخل ہو جائے تو ایکشن منسوخ ہو جاتا ہے۔ README کے مطابق، استعمال سے پہلے نشانہ باندھنے اور attack window کو مزید محدود کرنے سے مقامی tuning نے فی bed نقصان 11 سے بڑھا کر 46 کر دیا۔

آخری تصدیق شدہ run میں پہلی landing پر چھ bed explosions سے dragon ہلاک ہو گیا۔ تاہم، dragon کی پرواز اور landing کا وقت ہر run میں مختلف ہو سکتا ہے، اس لیے یکساں completion times کی ضمانت نہیں دی جا سکتی۔

combat lab درست طریقے سے استعمال کریں

combat-lab ڈائریکٹری ایک الگ test environment ہے۔ اس میں تیار شدہ positions، inventories، اور دیگر test changes استعمال ہو سکتے ہیں۔ اس کا hardcoded driver، combat-probe.mjs، port 25577 استعمال کرتا ہے اور کسی بھی model کو call نہیں کرتا۔

combat-lab کے نتیجے کو کبھی بھی مکمل model-controlled Survival run کے طور پر پیش نہ کریں۔ Lab results الگ تھلگ combat behavior کی توثیق کرتے ہیں، empty inventory سے شروع ہونے والے مکمل route کی نہیں۔

Advanced recording اور verification tips

Information overlay شامل کریں اور اس کی توثیق کریں

ریپوزٹری ایک overlay workflow درج کرتی ہے جو اوپر ایک شفاف banner شامل کرتا ہے۔ اس میں model names، گزرے ہوئے milliseconds، XYZ coordinates، planner objective، اور منتخب کردہ action دکھائے جاتے ہیں۔ یہ labels ریکارڈ شدہ model responses اور game events پر مبنی ہوتے ہیں۔

دستاویزی مثال والے run کے لیے overlay اس طرح بنائیں اور verify کریں:

node overlay.mjs nether-final-02
node verify-run.mjs nether-final-02 nether-final-02 full-playthrough-overlay.mp4

پرانے Prismarine Viewer recording کے لیے دستاویزی commands یہ ہیں:

node assemble-video.mjs recorded-06
node verify-run.mjs recorded-06

پرانا recorded-06 workflow Prismarine Viewer اور custom HUD استعمال کرتا تھا۔ نئی recordings read-only protocol mirror کے ذریعے official Minecraft Java 1.16.5 client استعمال کرتی ہیں۔

Pauses اور code-update history محفوظ رکھیں

اگر recording میں متعدد capture files ہوں کیونکہ agent کو code update درکار تھا، تو gameplay کے ہر فعال حصے کو محفوظ رکھیں۔ combined video میں ہر update pause کو نشان زد کریں اور تمام deaths اور pauses رپورٹ کریں۔ ایسے run کو uninterrupted یا deathless نہ بیان کریں، جب تک یہ وضاحت درست نہ ہو۔

غیر محفوظ portal entry strategies سے بچیں

ایک lab test سے معلوم ہوا کہ End portal میں طویل گراوٹ fall damage کو End تک منتقل کر سکتی ہے۔ recorded route نے اس strategy کو مسترد کیا اور اس کے بجائے مختصر، جانچے ہوئے downward-mining steps استعمال کیے۔ route behavior میں ترمیم کرتے وقت اس safety constraint کو برقرار رکھیں۔

Victory کو terminal رکھیں

موجودہ implementation victory کے بعد کسی اور game action کو روکتی ہے۔ اگر آپ action loop میں ترمیم کریں تو اس behavior کو برقرار رکھیں، کیونکہ victory کے بعد کے actions logs اور recordings کی تشریح مشکل بنا سکتے ہیں۔

Local artifacts کو Git سے باہر رکھیں

Recordings اور generated evidence دانستہ طور پر local رہتے ہیں۔ تازہ ترین video کا دستاویزی path runs/nether-final-08/full-playthrough-banner.mp4 ہے، جبکہ اس کی verification، timing comparison، اور action log اسی run directory میں موجود ہیں۔ Recordings، downloaded runtimes، server binaries، worlds، یا credentials کو commit نہ کریں۔

Troubleshooting checklist

  • Agent شروع نہیں ہوتا: تصدیق کریں کہ mirror port 25578 پر listening کر رہا ہے اور native client connect ہو چکا ہے۔ WAIT_NATIVE=1 کے ساتھ انتظار متوقع ہے۔
  • Model requests ناکام ہوتی ہیں: Google Application Default Credentials، Secret Manager permissions، model-relay.mjs اور models.mjs میں project اور secret references، port 3099 پر relay availability، اور OpenRouter credit کی تصدیق کریں۔
  • Run پرانی world میں شروع ہوتا ہے: server روکیں اور واقعی غیر استعمال شدہ level-name مقرر کریں۔ صرف نئی run directory بنانا کافی نہیں ہے۔
  • Dragon observations دستیاب نہیں ہیں: observer build کریں، اس کے sensor کے ساتھ server شروع کریں، اور تصدیق کریں کہ agent DRAGON_SENSOR_URL=http://127.0.0.1:3093 استعمال کر رہا ہے۔
  • Finished recording marker ظاہر نہیں ہوتا: native client کو اس وقت تک چلتا رہنے دیں جب تک full-playthrough.mp4.finished.json لکھا نہ جائے۔
  • Platform-specific path ناکام ہوتا ہے: Java، Minecraft runtime، native client، اور server paths کو ایڈجسٹ کریں، کیونکہ فراہم کردہ scripts macOS پر تیار کیے گئے تھے۔

نتیجہ

Astra اور JEV project ایک unrestricted game bot کے بجائے structured، evidence-oriented Minecraft agent پیش کرتا ہے۔ Astra یا Sol route کی planning کرتا ہے، JEV محدود actions منتخب کرتا ہے، Mineflayer انہیں normal protocol کے ذریعے execute کرتا ہے، اور read-only sensor درست dragon combat کی معاونت کرتا ہے۔ ایک قابل اعتماد run کے لیے credentials کا محتاط انتظام، واقعی fresh world، synchronized native recording، محفوظ logs، automated tests، اور game state اور video evidence دونوں کا final review ضروری ہے۔

متعلقہ بنیادوں کے لیے TypeSafe کا سرکاری تعارف، Mineflayer کی ریپوزٹری، اور Astra ماڈل کی سرکاری دستاویزات ملاحظہ کریں۔