کیا نیا گیم 2 کے قسط 1 میں واقعی ایک لامحدود لوپ ہے؟

AIMBOT 2.0

نیو گیم 2 کے قسط 1 میں ، تقریبا 9:40 بجے ، نین نے لکھا ہوا کوڈ کا ایک شاٹ ہے:

ترجمہ شدہ تبصروں کے ساتھ یہ متن کی شکل میں ہے۔

// the calculation of damage when attacked void DestructibleActor::ReceiveDamage(float sourceDamage) { // apply debuffs auto resolvedDamage = sourceDamage; for (const auto& debuf:m_debufs) { resolvedDamage = debuf.ApplyToDamage(resolvedDamage); m_currentHealth -= resolvedDamage if (m_currentHealth <= 0.f) { m_currentHealth = 0.f; DestroyMe(); } } } 

گولی مار دینے کے بعد ، عمیکو نے لوپ لوپ کی طرف اشارہ کرتے ہوئے کہا کہ کوڈ گرنے کی وجہ یہ ہے کہ یہاں لامحدود لوپ موجود ہے۔

مجھے سچ میں C ++ نہیں معلوم ہے لہذا مجھے یقین نہیں ہے کہ وہ جو کہہ رہی ہے وہ سچ ہے یا نہیں۔

میں جو دیکھ سکتا ہوں ، اس سے لے کر لوپ صرف ان ڈیبس کے ذریعہ دوبارہ چل رہا ہے جو اداکار کے پاس فی الحال ہے۔ جب تک کہ اداکار کے پاس لامحدود تعداد میں ڈیبس نہ ہوں ، مجھے نہیں لگتا کہ یہ ممکنہ طور پر لامحدود لوپ بن سکتا ہے۔

لیکن مجھے یقین نہیں ہے کیوں کہ کوڈ کو مارنے کی واحد وجہ یہ ہے کہ وہ یہاں ایسٹر انڈا رکھنا چاہتے ہیں ، ٹھیک ہے؟ ہم نے ابھی لیپ ٹاپ کے پچھلے حصے کا شاٹ حاصل کیا ہوگا اور امیکو کو یہ کہتے ہوئے سنا ہوگا کہ "اوہ آپ کو وہاں لامحدود لوپ مل گیا ہے"۔ حقیقت یہ ہے کہ انہوں نے حقیقت میں کچھ کوڈ دکھایا ہے مجھے یہ سوچنے پر مجبور کرتا ہے کہ کسی طرح یہ کوڈ کسی طرح کا ایسٹر انڈا ہے۔

کیا کوڈ دراصل لامحدود لوپ پیدا کرے گا؟

8

• شاید مددگار: امیکو کا اضافی اسکرین شاٹ یہ کہتے ہوئے کہ "یہ تھا اسی آپریشن کو بلا رہا ہے بار بار "، جو کوڈ میں نہیں دکھایا جاسکتا ہے۔
• اوہ! مجھے یہ معلوم نہیں تھا! @ اکی ٹناکا سب نے جو دیکھا میں کہا "لامحدود لوپ"
• ٹویٹ ایمبیڈ کریں یہ صرف اتنا نہیں ہے کہ او پی میں کسی ماخذ کوڈ کے بارے میں سوال ہے جو کسی موبائل فون سے آیا ہے۔ او پی کا سوال کسی خاص بیان کے بارے میں ہے کے بارے میں موبائل فون میں کسی کردار کے ذریعہ سورس کوڈ ، اور موبائل فون سے متعلق ایک جواب موجود ہے ، یعنی "کروچیرل ڈو گوفڈ اور لائن کا غلط ترجمہ کیا گیا"۔
• @ ایسنشین مجھے لگتا ہے کہ آپ اصل میں پوچھے جانے والے سوالوں کی بجائے ، جو آپ سوال چاہتے ہیں اس کو پڑھ رہے ہیں۔ سوال کچھ ماخذ کوڈ فراہم کرتا ہے اور پوچھتا ہے کہ کیا یہ حقیقی زندگی کے C ++ کوڈ کے طور پر لامحدود لوپ پیدا کرتا ہے؟ نیا کھیل! ایک غیر حقیقی کام ہے۔ حقیقی زندگی کے معیارات کے مطابق کرنے کے لئے اس میں کوڈ پیش کرنے کی ضرورت نہیں ہے۔ امیکو کوڈ کے بارے میں جو کچھ کہتا ہے وہ کسی بھی C ++ معیارات یا مرتب کرنے والوں سے زیادہ مستند ہے۔ اعلی (قبول شدہ) جواب میں کائنات میں موجود کسی بھی معلومات کا کوئی ذکر نہیں ہے۔ میرے خیال میں اچھ answerا جواب کے ساتھ اس بارے میں موضوع سے متعلق سوال پوچھا جاسکتا ہے ، لیکن جیسا کہ یہ بیان کیا گیا ہے وہ ایسا نہیں ہے۔

کوڈ لامحدود لوپ نہیں ہے بلکہ یہ ایک بگ ہے۔

یہاں دو (ممکنہ طور پر تین) مسائل ہیں:

• اگر کوئی ڈیبف موجود نہیں ہیں تو کسی بھی قسم کا نقصان نہیں ہوگا
• اگر 1 سے زیادہ ڈیبٹ ہونے کی صورت میں ضرورت سے زیادہ نقصان ہوگا
• اگر ڈسٹرمائ () فوری طور پر آبجیکٹ کو حذف کردیتی ہے اور اب بھی عمل میں آنے والے m_debufs موجود ہیں تو لوپ کسی حذف شدہ آبجیکٹ پر عملدرآمد کرے گا اور میموری کو کچل دے گا۔ زیادہ تر گیم انجنوں کو اس کے ارد گرد کام کرنے کے لئے تباہی کی قطار موجود ہے اور اس سے زیادہ تاکہ یہ مسئلہ نہ ہو۔

نقصان کا اطلاق لوپ سے باہر ہونا چاہئے۔

یہ صحیح فعل یہ ہے:

// the calculation of damage when attacked void DestructibleActor::ReceiveDamage(float sourceDamage) { // apply debuffs auto resolvedDamage = sourceDamage; for (const auto& debuf:m_debufs) { resolvedDamage = debuf.ApplyToDamage(resolvedDamage); } m_currentHealth -= resolvedDamage if (m_currentHealth <= 0.f) { m_currentHealth = 0.f; DestroyMe(); } } 

12

• 15 کیا ہم کوڈ ریویو پر ہیں؟ : ڈی
• اگر آپ 16777216 HP سے اوپر نہیں جاتے ہیں تو 4 فلوٹ صحت کے ل great بہترین ہیں۔ یہاں تک کہ آپ کسی دشمن کو پیدا کرنے کے ل health صحت کو لامحدود قرار دے سکتے ہیں لیکن آپ مر نہیں سکتے ہیں ، اور لاتعداد نقصان کا استعمال کرتے ہوئے یکسوئی حملہ ہوتا ہے جو اب بھی لامحدود HP کردار کو نہیں مارے گا (INF-INF کا نتیجہ NaN ہے) لیکن سب کچھ مار ڈالیں گے۔ تو یہ بہت مفید ہے۔
• 1 @ cat بہت سے کوڈنگ معیارات میں کنونشن کے ذریعہ m_ سابقہ ​​کا مطلب ہے یہ ممبر متغیر ہے۔ اس معاملے میں ایک ممبر متغیر DestructibleActor.
• 2 @ ہوٹیل کیلیفورنیا میں اتفاق کرتا ہوں کہ اس کے لئے ایک چھوٹا سا موقع ہے ApplyToDamage توقع کے مطابق کام نہیں کرتا ہے لیکن مثال کے طور پر آپ جو دیں گے میں کہوں گا ApplyToDamage بھی اس کو اصل سے گزرنے کے لئے دوبارہ کام کرنے کی ضرورت ہے sourceDamage نیز اس کے ساتھ ہی یہ ان معاملات میں ڈیبف کا صحیح طور پر حساب لگاسکتا ہے۔ مطلق پیڈینٹ بننے کے لئے: اس مقام پر ڈی ایم جی معلومات ایک ڈھانچہ ہونا چاہئے جس میں اصل ڈی ایم جی ، موجودہ ڈی ایم جی ، اور نقصان (نوعیت) کی نوعیت بھی شامل ہے اگر نیز ڈیفس میں "فائر کرنے کا خطرہ" جیسی چیزیں ہوں۔ تجربے سے کہیں زیادہ وقت نہیں گزرتا ہے جب ڈیبس کے ساتھ کسی گیم ڈیزائن کا مطالبہ کریں۔
• 1StephaneHockenhull نے اچھی طرح کہا!

ایسا نہیں لگتا ہے کہ کوڈ لامحدود لوپ تخلیق کرے گا۔

لوپ لامحدود ہونے کا واحد راستہ ہوتا

debuf.ApplyToDamage(resolvedDamage); 

یا

DestroyMe(); 

میں نئی ​​اشیاء شامل کرنا تھا m_debufs کنٹینر

ایسا ناممکن لگتا ہے۔ اور اگر یہ بات ہوتی تو پروگرام دوبارہ چلنے کے ساتھ ہی کنٹینر کو تبدیل کرنے کی وجہ سے کریش ہوسکتا ہے۔

یہ پروگرام غالبا to کال کرنے کی وجہ سے کریش ہو گا DestroyMe(); جو شاید موجودہ شے کو خارج کر دیتا ہے جو اس وقت لوپ چلارہا ہے۔

ہم اسے کارٹون کے طور پر سوچ سکتے ہیں جہاں 'برا آدمی' شاخ کو 'اچھے آدمی' کے ساتھ گرنے کے ل saw دیکھتا ہے ، لیکن بہت دیر سے پتہ چلتا ہے کہ وہ کٹ کے غلط رخ پر ہے۔ یا مڈ گارڈ سانپ اپنی دم کا کھا رہا ہے۔

---

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

---

اکی تاناکا کے تبصرے کی بنیاد پر ،

ممکنہ مددگار: امیکو کا اضافی اسکرین شاٹ یہ کہتے ہوئے کہ "یہ بار بار ایک ہی کارروائی کو کہتے ہیں" ، جو کوڈ میں نہیں دکھایا جاسکتا ہے۔

"یہ بار بار اسی آپریشن کو بلا رہا ہے۔" اس کا امکان زیادہ ہے۔

یہ سوچتے ہیں کہ DestroyMe(); یہ ایک سے زیادہ مرتبہ فون کرنے کے لئے ڈیزائن نہیں کیا گیا ہے ، اس کے حادثے کا امکان زیادہ ہے۔

اس مسئلے کو حل کرنے کا ایک طریقہ یہ ہے کہ اس کو تبدیل کیا جائے if اس طرح کے لئے:

 if (m_currentHealth <= 0.f) { m_currentHealth = 0.f; DestroyMe(); break; } 

جب اس ڈوسٹروکٹیبل ایکٹر کو تباہ کر دیا جائے تو اس لوپ سے باہر آجائیں گے ، اس بات کو یقینی بناتے ہوئے کہ 1) DestroyMe طریقہ صرف ایک بار کہا جاتا ہے اور 2) ایک بار جب مقصد پہلے ہی مردہ سمجھا جاتا ہے تو اسے بیکار استعمال نہ کریں۔

2

• 1 جب صحت <= 0 یقینی بنائے تو صحت سے متعلق جانچ پڑتال کرنے کے لئے لوپ کے انتظار کرنے سے بہتر ہوجانا بہتر ہے۔
• مجھے لگتا ہے کہ میں شاید break لوپ سے باہر ، اور پھر کال کریں DestroyMe()، صرف محفوظ رہنے کے لئے

کوڈ کے ساتھ متعدد مسائل ہیں۔

1. اگر کوئی ڈیبف نہیں ہیں تو ، کوئی نقصان نہیں اٹھایا جائے گا۔
2. DestroyMe() تقریب کا نام خطرناک لگتا ہے۔ اس پر منحصر ہے کہ اس کو کیسے نافذ کیا گیا ، یہ مسئلہ بن سکتا ہے یا نہیں۔ اگر یہ کسی فنکشن میں لپیٹ کر موجودہ آبجیکٹ کے ڈسٹرکٹر کے لئے صرف ایک کال ہے ، تو پھر ایک مسئلہ ہے ، کیونکہ اس کوڈ کو چلانے والے کوڈ کو اس کے وسط میں ختم کردیا جائے گا۔ اگر یہ کسی ایسے فنکشن میں کال ہے جو موجودہ آبجیکٹ کے حذف ہونے کے واقعہ کی قطار بنائے گی ، تو پھر کوئی مسئلہ نہیں ہے ، کیوں کہ اس کی عمل آوری مکمل ہونے کے بعد آبجیکٹ کو ختم کردیا جائے گا اور ایونٹ لوپ کک ہوجاتا ہے۔
3. ایسا لگتا ہے کہ اصل مسئلے کا انیمیشن میں ذکر کیا گیا ہے ، "یہ بار بار ایک ہی کارروائی کو کہتے ہیں"۔ DestroyMe() جب تک m_currentHealth <= 0.f اور اعادہ کرنے کے لئے اور بھی خرابیاں باقی ہیں ، جس کا نتیجہ ہوسکتا ہے DestroyMe() بار بار کہا جاتا ہے۔ پہلے کے بعد لوپ رک جانا چاہئے DestroyMe() کال کریں ، کیوں کہ کسی چیز کو ایک سے زیادہ بار حذف کرنے سے میموری کی بدعنوانی آجاتی ہے ، جس کا نتیجہ طویل عرصے میں کریش ہوجائے گا۔

مجھے واقعی یقین نہیں ہے کہ ہر ایک ڈیف صحت کو صرف ایک بار لے جانے کے بجائے صحت کو کیوں لے جاتا ہے ، لے جانے والے ابتدائی نقصان پر تمام خرابی کے اثرات لاگو ہوتے ہیں ، لیکن میں یہ سمجھاؤں گا کہ یہ صحیح کھیل کی منطق ہے۔

صحیح کوڈ ہوگا

// the calculation of damage when attacked void DestructibleActor::ReceiveDamage(float sourceDamage) { // apply debuffs auto resolvedDamage = sourceDamage; for (const auto& debuf:m_debufs) { resolvedDamage = debuf.ApplyToDamage(resolvedDamage); m_currentHealth -= resolvedDamage if (m_currentHealth <= 0.f) { m_currentHealth = 0.f; DestroyMe(); break; } } } 

3

• مجھے یہ بتانا چاہئے کہ جیسا کہ میں نے ماضی میں میموری مختص کرنے والوں کو لکھا ہے ، اسی میموری کو حذف کرنا کوئی مسئلہ نہیں بنتا ہے۔ یہ بے کار بھی ہوسکتا ہے۔ یہ سب مختص کرنے والے کے طرز عمل پر منحصر ہے۔ مائن نے ابھی ایک نچلی سطح سے منسلک فہرست کی طرح کام کیا لہذا حذف شدہ اعداد و شمار کے لئے "نوڈ" یا تو کئی بار مفت سیٹ ہو جاتا ہے یا کئی بار دوبارہ ختم ہوجاتا ہے (جو صرف بیکار پوائنٹر ری ڈائریکشنز کے مساوی ہوگا)۔ اگرچہ اچھی کیچ
• ڈبل فری ایک بگ ہے ، اور عام طور پر غیر وضاحتی رویے اور کریشوں کا باعث بنتا ہے۔ یہاں تک کہ اگر آپ کے پاس کسٹم مختص کرنے والا ہے جو کسی طرح ایک ہی میموری ایڈریس کے دوبارہ استعمال کی اجازت نہیں دیتا ہے تو ، ڈبل فری ایک بدبودار کوڈ ہے کیونکہ اس سے کوئی معنی نہیں آتا ہے اور آپ جامد کوڈ تجزیہ کاروں کے ذریعہ چل پڑے گے۔
• بلکل! میں نے اسے اس مقصد کے لئے ڈیزائن نہیں کیا تھا۔ کچھ زبانیں صرف خصوصیات کی کمی کی وجہ سے مختص کی ضرورت ہوتی ہیں۔ نہیں نہیں نہیں. میں صرف یہ کہہ رہا تھا کہ حادثے کی ضمانت نہیں ہے۔ کچھ مخصوص ڈیزائن کی درجہ بندی ہمیشہ خراب نہیں ہوتی۔