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(); } } } ಶಾಟ್ ನಂತರ, ಫಾರ್ ಲೂಪ್ ಅನ್ನು ಸೂಚಿಸುವ ಉಮಿಕೊ, ಕೋಡ್ ಕ್ರ್ಯಾಶ್ ಆಗಲು ಕಾರಣವೆಂದರೆ ಅನಂತ ಲೂಪ್ ಇದೆ.
ನನಗೆ ನಿಜವಾಗಿಯೂ ಸಿ ++ ಗೊತ್ತಿಲ್ಲ ಆದ್ದರಿಂದ ಅವಳು ಹೇಳುತ್ತಿರುವುದು ನಿಜವೇ ಎಂದು ನನಗೆ ಖಚಿತವಿಲ್ಲ.
ನಾನು ನೋಡುವುದರಿಂದ, ಫಾರ್ ಲೂಪ್ ನಟನು ಪ್ರಸ್ತುತ ಹೊಂದಿರುವ ಡೀಬಫ್‌ಗಳ ಮೂಲಕ ಪುನರಾವರ್ತಿಸುತ್ತಿದೆ. ನಟನು ಅನಂತ ಪ್ರಮಾಣದ ಡೀಬಫ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಅದು ಅನಂತ ಲೂಪ್ ಆಗಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುವುದಿಲ್ಲ.
ಆದರೆ ನನಗೆ ಖಾತ್ರಿಯಿಲ್ಲ ಏಕೆಂದರೆ ಕೋಡ್‌ನ ಶಾಟ್ ಇರುವ ಏಕೈಕ ಕಾರಣವೆಂದರೆ ಅವರು ಈಸ್ಟರ್ ಎಗ್ ಅನ್ನು ಇಲ್ಲಿ ಹಾಕಲು ಬಯಸಿದ್ದರು, ಸರಿ? ನಾವು ಲ್ಯಾಪ್ಟಾಪ್ನ ಹಿಂಭಾಗದ ಹೊಡೆತವನ್ನು ಪಡೆದಿದ್ದೇವೆ ಮತ್ತು ಉಮಿಕೊ "ಓಹ್ ನಿಮಗೆ ಅಲ್ಲಿ ಅನಂತ ಲೂಪ್ ಸಿಕ್ಕಿದೆ" ಎಂದು ಹೇಳುವುದನ್ನು ಕೇಳುತ್ತಿದ್ದೆವು. ಅವರು ನಿಜವಾಗಿಯೂ ಕೆಲವು ಕೋಡ್ ಅನ್ನು ತೋರಿಸಿದ್ದಾರೆ ಎಂಬ ಅಂಶವು ಹೇಗಾದರೂ ಕೋಡ್ ಒಂದು ರೀತಿಯ ಈಸ್ಟರ್ ಎಗ್ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ಕೋಡ್ ವಾಸ್ತವವಾಗಿ ಅನಂತ ಲೂಪ್ ಅನ್ನು ರಚಿಸುತ್ತದೆಯೇ?
8- ಬಹುಶಃ ಸಹಾಯಕವಾಗಿದೆಯೆ: ಉಮಿಕೊ ಅವರ ಹೆಚ್ಚುವರಿ ಸ್ಕ್ರೀನ್‌ಶಾಟ್ "ಅದು ಅದೇ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಕರೆಯುತ್ತದೆ ಪದೇ ಪದೇ ", ಇದನ್ನು ಕೋಡ್‌ನಲ್ಲಿ ತೋರಿಸಲಾಗುವುದಿಲ್ಲ.
- ಓಹ್! ಅದು ನನಗೆ ತಿಳಿದಿರಲಿಲ್ಲ! ನಾನು ನೋಡಿದ ಅಕಿಟಾನಕಾ ಸಬ್ "ಅನಂತ ಲೂಪ್" ಎಂದು ಹೇಳುತ್ತದೆ
- Og ಲೋಗನ್ ನಾನು ನಿಜವಾಗಿಯೂ ಒಪ್ಪುವುದಿಲ್ಲ. ಅನಿಮೆನಿಂದ ಬಂದ ಕೆಲವು ಮೂಲ ಕೋಡ್ ಬಗ್ಗೆ ಒಪಿಗೆ ಪ್ರಶ್ನೆ ಇದೆ ಎಂಬುದು ಮಾತ್ರವಲ್ಲ; ಒಪಿಯ ಪ್ರಶ್ನೆಯು ಒಂದು ನಿರ್ದಿಷ್ಟ ಹೇಳಿಕೆಯ ಬಗ್ಗೆ ಬಗ್ಗೆ ಅನಿಮೆನಲ್ಲಿನ ಅಕ್ಷರದಿಂದ ಮೂಲ ಕೋಡ್, ಮತ್ತು ಅನಿಮೆ-ಸಂಬಂಧಿತ ಉತ್ತರವಿದೆ, ಅವುಗಳೆಂದರೆ "ಕ್ರಂಚೈರಾಲ್ ಗೂಫ್ಡ್ ಮತ್ತು ಲೈನ್ ಅನ್ನು ತಪ್ಪಾಗಿ ಅನುವಾದಿಸಿದ್ದಾರೆ".
- en ಸೆನ್ಶಿನ್ ನಿಜವಾಗಿ ಕೇಳುವ ಬದಲು ನೀವು ಏನನ್ನು ಬಯಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ನೀವು ಓದುತ್ತಿದ್ದೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಪ್ರಶ್ನೆಯು ಕೆಲವು ಮೂಲ ಕೋಡ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು ಇದು ಅನಂತ ಲೂಪ್ ಅನ್ನು ನಿಜ ಜೀವನದ ಸಿ ++ ಕೋಡ್ ಆಗಿ ಉತ್ಪಾದಿಸುತ್ತದೆಯೇ ಎಂದು ಕೇಳುತ್ತದೆ. ಹೊಸ ಆಟ! ಒಂದು ಕಾಲ್ಪನಿಕ ಕೃತಿ; ನಿಜ ಜೀವನದ ಮಾನದಂಡಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ಕೋಡ್ ಅನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಕೋಡ್ ಬಗ್ಗೆ ಉಮಿಕೊ ಏನು ಹೇಳುತ್ತಾರೆಂದರೆ ಯಾವುದೇ ಸಿ ++ ಮಾನದಂಡಗಳು ಅಥವಾ ಕಂಪೈಲರ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಅಧಿಕೃತವಾಗಿದೆ. ಮೇಲಿನ (ಸ್ವೀಕರಿಸಿದ) ಉತ್ತರದಲ್ಲಿ ಯಾವುದೇ ವಿಶ್ವ ಮಾಹಿತಿಯ ಉಲ್ಲೇಖವಿಲ್ಲ. ವಿಷಯದ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಯನ್ನು ಉತ್ತಮ ಉತ್ತರದೊಂದಿಗೆ ಕೇಳಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಆದರೆ ರಚಿಸಿದಂತೆ ಇದು ಅಲ್ಲ.
ಕೋಡ್ ಅನಂತ ಲೂಪ್ ಅಲ್ಲ ಆದರೆ ಅದು ದೋಷವಾಗಿದೆ.
ಎರಡು (ಬಹುಶಃ ಮೂರು) ಸಮಸ್ಯೆಗಳಿವೆ:
- ಯಾವುದೇ ಡೀಫಫ್‌ಗಳು ಇಲ್ಲದಿದ್ದರೆ ಯಾವುದೇ ಹಾನಿಯನ್ನು ಅನ್ವಯಿಸುವುದಿಲ್ಲ
- 1 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಡೀಬಫ್ ಇದ್ದರೆ ಅತಿಯಾದ ಹಾನಿಯನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ
- DestroyMe () ತಕ್ಷಣ ವಸ್ತುವನ್ನು ಅಳಿಸಿದರೆ ಮತ್ತು ಇನ್ನೂ 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(); } } - ನಾವು ಕೋಡ್ ವಿಮರ್ಶೆಯಲ್ಲಿದ್ದೇವೆಯೇ? : ಡಿ
- ನೀವು 16777216 ಎಚ್‌ಪಿಗೆ ಹೋಗದಿದ್ದರೆ 4 ಫ್ಲೋಟ್‌ಗಳು ಆರೋಗ್ಯಕ್ಕೆ ಅದ್ಭುತವಾಗಿದೆ. ನೀವು ಹೊಡೆಯಬಹುದಾದ ಆದರೆ ಸಾಯುವುದಿಲ್ಲ ಎಂದು ಶತ್ರುವನ್ನು ರಚಿಸಲು ನೀವು ಆರೋಗ್ಯವನ್ನು ಅನಂತಕ್ಕೆ ಹೊಂದಿಸಬಹುದು, ಮತ್ತು ಅನಂತ ಹಾನಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಒಂದು-ಕೊಲ್ಲುವ ದಾಳಿಯನ್ನು ಹೊಂದಬಹುದು, ಅದು ಇನ್ನೂ ಅನಂತ HP ಅಕ್ಷರವನ್ನು ಕೊಲ್ಲುವುದಿಲ್ಲ (INF-INF ನ ಫಲಿತಾಂಶ NaN ಆಗಿದೆ) ಆದರೆ ಉಳಿದಂತೆ ಕೊಲ್ಲುತ್ತದೆ. ಆದ್ದರಿಂದ ಇದು ತುಂಬಾ ಉಪಯುಕ್ತವಾಗಿದೆ.
- 1 at ಕ್ಯಾಟ್ ಅನೇಕ ಕೋಡಿಂಗ್ ಮಾನದಂಡಗಳಲ್ಲಿ ಸಮಾವೇಶದ ಮೂಲಕ
m_ಪೂರ್ವಪ್ರತ್ಯಯ ಎಂದರೆ ಅದು ಸದಸ್ಯ ವೇರಿಯಬಲ್. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸದಸ್ಯ ವೇರಿಯಬಲ್DestructibleActor. - 2 ot ಹೋಟೆಲ್ ಕ್ಯಾಲಿಫೋರ್ನಿಯಾ ಒಂದು ಸಣ್ಣ ಅವಕಾಶವಿದೆ ಎಂದು ನಾನು ಒಪ್ಪುತ್ತೇನೆ
ApplyToDamageನಿರೀಕ್ಷೆಯಂತೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಆದರೆ ನೀವು ನೀಡುವ ಉದಾಹರಣೆಯಲ್ಲಿ ನಾನು ಹೇಳುತ್ತೇನೆApplyToDamageಸಹ ಅದನ್ನು ಮೂಲವನ್ನು ಹಾದುಹೋಗುವ ಅಗತ್ಯವಿರುವಂತೆ ಪುನಃ ಕೆಲಸ ಮಾಡಬೇಕಾಗಿದೆsourceDamageಆ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅದು ಡೀಬಫ್ ಅನ್ನು ಸರಿಯಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ. ಸಂಪೂರ್ಣ ಪೆಡೆಂಟ್ ಆಗಲು: ಈ ಸಮಯದಲ್ಲಿ ಡಿಎಂಜಿ ಮಾಹಿತಿಯು ಮೂಲ ಡಿಎಂಜಿ, ಪ್ರಸ್ತುತ ಡಿಎಂಜಿ, ಮತ್ತು ಹಾನಿಯ (ಗಳ) ಸ್ವರೂಪವನ್ನು ಒಳಗೊಂಡಿರುವ ಒಂದು ರಚನೆಯಾಗಿರಬೇಕು ಮತ್ತು ಡೀಬಫ್‌ಗಳು "ಬೆಂಕಿಯ ದುರ್ಬಲತೆ" ಯಂತಹ ವಿಷಯಗಳನ್ನು ಹೊಂದಿದ್ದರೆ. ಅನುಭವದಿಂದ ಡಿಬಫ್‌ಗಳೊಂದಿಗಿನ ಯಾವುದೇ ಆಟದ ವಿನ್ಯಾಸವು ಇವುಗಳನ್ನು ಬೇಡಿಕೆಯಿಡಲು ಬಹಳ ಸಮಯವಲ್ಲ. - 1 ಸ್ಟೆಫೇನ್ಹಾಕನ್ಹಲ್ ಚೆನ್ನಾಗಿ ಹೇಳಿದರು!
ಕೋಡ್ ಅನಂತ ಲೂಪ್ ಅನ್ನು ರಚಿಸುವಂತೆ ತೋರುತ್ತಿಲ್ಲ.
ಒಂದು ವೇಳೆ ಲೂಪ್ ಅನಂತವಾಗಿರುತ್ತದೆ
debuf.ApplyToDamage(resolvedDamage); ಅಥವಾ
DestroyMe(); ಗೆ ಹೊಸ ವಸ್ತುಗಳನ್ನು ಸೇರಿಸುವುದು m_debufs ಧಾರಕ.
ಇದು ಅಸಂಭವವೆಂದು ತೋರುತ್ತದೆ. ಮತ್ತು ಅದು ನಿಜವಾಗಿದ್ದರೆ, ಪುನರಾವರ್ತಿಸುವಾಗ ಕಂಟೇನರ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದರಿಂದ ಪ್ರೋಗ್ರಾಂ ಕ್ರ್ಯಾಶ್ ಆಗಬಹುದು.
ಕರೆ ಮಾಡಿದ ಕಾರಣ ಪ್ರೋಗ್ರಾಂ ಹೆಚ್ಚಾಗಿ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ DestroyMe(); ಇದು ಪ್ರಸ್ತುತ ಲೂಪ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಸ್ತುತ ವಸ್ತುವನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ.
ಕಾರ್ಟೂನ್ ಎಂದು ನಾವು ಭಾವಿಸಬಹುದು, ಅಲ್ಲಿ 'ಕೆಟ್ಟ ವ್ಯಕ್ತಿ' ಒಂದು ಶಾಖೆಯನ್ನು 'ಒಳ್ಳೆಯ ವ್ಯಕ್ತಿ' ಬೀಳುವಂತೆ ನೋಡುತ್ತಾನೆ, ಆದರೆ ಅವನು ಕಟ್ನ ತಪ್ಪು ಬದಿಯಲ್ಲಿದ್ದಾನೆ ಎಂದು ತಡವಾಗಿ ಅರಿತುಕೊಳ್ಳುತ್ತಾನೆ. ಅಥವಾ ಮಿಡ್‌ಗಾರ್ಡ್ ಹಾವು ತಿನ್ನುವುದು ಅದರ ಸ್ವಂತ ಬಾಲ.
ಅನಂತ ಲೂಪ್ನ ಸಾಮಾನ್ಯ ಲಕ್ಷಣವೆಂದರೆ ಅದು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಹೆಪ್ಪುಗಟ್ಟುತ್ತದೆ ಅಥವಾ ಸ್ಪಂದಿಸದಂತೆ ಮಾಡುತ್ತದೆ ಎಂದು ನಾನು ಸೇರಿಸಬೇಕು. ಅದು ಪದೇ ಪದೇ ಮೆಮೊರಿಯನ್ನು ನಿಯೋಜಿಸಿದರೆ ಅಥವಾ ಶೂನ್ಯದಿಂದ ಅಥವಾ ಇಷ್ಟಗಳಿಂದ ಭಾಗಿಸುವ ಯಾವುದನ್ನಾದರೂ ಮಾಡಿದರೆ ಅದು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡುತ್ತದೆ.
ಅಕಿ ತನಕಾ ಅವರ ಕಾಮೆಂಟ್ ಆಧರಿಸಿ,
ಬಹುಶಃ ಸಹಾಯಕವಾಗಿದೆಯೆ: "ಇದು ಒಂದೇ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಕರೆಯುತ್ತಿದೆ" ಎಂದು ಉಮಿಕೊ ಹೇಳುವ ಹೆಚ್ಚುವರಿ ಸ್ಕ್ರೀನ್‌ಶಾಟ್, ಇದನ್ನು ಕೋಡ್‌ನಲ್ಲಿ ತೋರಿಸಲಾಗುವುದಿಲ್ಲ.
"ಇದು ಮತ್ತೆ ಮತ್ತೆ ಅದೇ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಕರೆಯುತ್ತಿದೆ" ಇದು ಹೆಚ್ಚು ಸಾಧ್ಯತೆ.
ಊಹಿಸಿಕೊಂಡು DestroyMe(); ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಕರೆಯಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿಲ್ಲ, ಅದು ಕುಸಿತಕ್ಕೆ ಕಾರಣವಾಗುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು.
ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಮಾರ್ಗವೆಂದರೆ ಅದನ್ನು ಬದಲಾಯಿಸುವುದು if ಈ ರೀತಿಯದ್ದಕ್ಕಾಗಿ:
if (m_currentHealth <= 0.f) { m_currentHealth = 0.f; DestroyMe(); break; } ಡಿಸ್ಟ್ರಕ್ಟಿಬಲ್ ಆಕ್ಟರ್ ನಾಶವಾದಾಗ ಇದು ಲೂಪ್ನಿಂದ ನಿರ್ಗಮಿಸುತ್ತದೆ, 1) ದಿ DestroyMe ವಿಧಾನವನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು 2) ವಸ್ತುವನ್ನು ಈಗಾಗಲೇ ಸತ್ತರೆಂದು ಪರಿಗಣಿಸಿದ ನಂತರ ಬಫ್‌ಗಳನ್ನು ಅನುಪಯುಕ್ತವಾಗಿ ಅನ್ವಯಿಸಬೇಡಿ.
- 1 ಆರೋಗ್ಯವನ್ನು ಪರೀಕ್ಷಿಸಲು ಲೂಪ್ನಿಂದ ಹೊರಗುಳಿಯುವುದು <= 0 ಖಂಡಿತವಾಗಿಯೂ ಆರೋಗ್ಯವನ್ನು ಪರೀಕ್ಷಿಸಲು ಲೂಪ್ ನಂತರ ಕಾಯುವುದಕ್ಕಿಂತ ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ.
- ನಾನು ಬಹುಶಃ ಎಂದು ಭಾವಿಸುತ್ತೇನೆ
breakಲೂಪ್ನಿಂದ, ಮತ್ತು ನಂತರ ಕರೆ ಮಾಡಿDestroyMe(), ಸುರಕ್ಷಿತವಾಗಿರಲು
ಕೋಡ್‌ನೊಂದಿಗೆ ಹಲವಾರು ಸಮಸ್ಯೆಗಳಿವೆ:
- ಯಾವುದೇ ಡೀಫಫ್‌ಗಳಿಲ್ಲದಿದ್ದರೆ, ಯಾವುದೇ ಹಾನಿ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ.
DestroyMe()ಕಾರ್ಯದ ಹೆಸರು ಅಪಾಯಕಾರಿ ಎಂದು ತೋರುತ್ತದೆ. ಅದು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಂಡಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ, ಅದು ಸಮಸ್ಯೆಯಾಗಿರಬಹುದು ಅಥವಾ ಇರಬಹುದು. ಇದು ಒಂದು ಕಾರ್ಯದಲ್ಲಿ ಸುತ್ತುವ ಪ್ರಸ್ತುತ ವಸ್ತುವಿನ ವಿನಾಶಕನಿಗೆ ಕೇವಲ ಕರೆ ಆಗಿದ್ದರೆ, ನಂತರ ಒಂದು ಸಮಸ್ಯೆ ಇದೆ, ಏಕೆಂದರೆ ಅದು ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮಧ್ಯದಲ್ಲಿ ವಸ್ತುವನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ. ಇದು ಪ್ರಸ್ತುತ ವಸ್ತುವಿನ ಅಳಿಸುವಿಕೆಯ ಘಟನೆಯನ್ನು ಕ್ಯೂ ಮಾಡುವ ಒಂದು ಕಾರ್ಯಕ್ಕೆ ಕರೆ ಆಗಿದ್ದರೆ, ಯಾವುದೇ ಸಮಸ್ಯೆ ಇಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಅದರ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ ನಂತರ ಮತ್ತು ಈವೆಂಟ್ ಲೂಪ್ ಪ್ರಾರಂಭವಾದ ನಂತರ ಅದು ನಾಶವಾಗುತ್ತದೆ.- ಅನಿಮೆನಲ್ಲಿ ಉಲ್ಲೇಖಿಸಿರುವಂತೆ ಕಂಡುಬರುವ ನಿಜವಾದ ಸಮಸ್ಯೆ, "ಇದು ಒಂದೇ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಕರೆಯುತ್ತಿದೆ" - ಇದು ಕರೆ ಮಾಡುತ್ತದೆ
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; } } } - ನಾನು ಈ ಹಿಂದೆ ಮೆಮೊರಿ ಹಂಚಿಕೆಯನ್ನು ಬರೆದಿರುವಂತೆ, ಅದೇ ಮೆಮೊರಿಯನ್ನು ಅಳಿಸುವುದರಿಂದ ಸಮಸ್ಯೆಯಾಗಬೇಕಾಗಿಲ್ಲ ಎಂದು ನಾನು ಗಮನಿಸಬೇಕು. ಇದು ಅನಗತ್ಯವಾಗಿರಬಹುದು. ಇದು ಎಲ್ಲಾ ಹಂಚಿಕೆಯ ವರ್ತನೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಮೈನ್ ಕೇವಲ ಕಡಿಮೆ ಮಟ್ಟದ ಲಿಂಕ್ ಮಾಡಿದ ಪಟ್ಟಿಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸಿದೆ ಆದ್ದರಿಂದ ಅಳಿಸಿದ ಡೇಟಾಗೆ "ನೋಡ್" ಹಲವಾರು ಬಾರಿ ಉಚಿತವಾಗಿ ಹೊಂದಿಸಲ್ಪಡುತ್ತದೆ ಅಥವಾ ಹಲವಾರು ಬಾರಿ ಮರುಹೊಂದಿಸಲ್ಪಡುತ್ತದೆ (ಇದು ಅನಗತ್ಯ ಪಾಯಿಂಟರ್ ಪುನರ್ನಿರ್ದೇಶನಗಳಿಗೆ ಅನುಗುಣವಾಗಿರುತ್ತದೆ). ಉತ್ತಮ ಕ್ಯಾಚ್ ಆದರೂ.
- ಡಬಲ್-ಫ್ರೀ ಒಂದು ದೋಷ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ವಿವರಿಸಲಾಗದ ನಡವಳಿಕೆ ಮತ್ತು ಕ್ರ್ಯಾಶ್‌ಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಒಂದೇ ಮೆಮೊರಿ ವಿಳಾಸದ ಮರುಬಳಕೆಯನ್ನು ಹೇಗಾದರೂ ಅನುಮತಿಸದ ಕಸ್ಟಮ್ ಹಂಚಿಕೆಯನ್ನು ನೀವು ಹೊಂದಿದ್ದರೂ ಸಹ, ಡಬಲ್-ಫ್ರೀ ಒಂದು ನಾರುವ ಸಂಕೇತವಾಗಿದೆ ಏಕೆಂದರೆ ಅದು ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ ಮತ್ತು ಸ್ಥಿರ ಕೋಡ್ ವಿಶ್ಲೇಷಕರಿಂದ ನೀವು ಕೂಗುತ್ತೀರಿ.
- ಖಂಡಿತವಾಗಿ! ನಾನು ಅದನ್ನು ಆ ಉದ್ದೇಶಕ್ಕಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಿಲ್ಲ. ಕೆಲವು ಭಾಷೆಗಳಿಗೆ ವೈಶಿಷ್ಟ್ಯಗಳ ಕೊರತೆಯಿಂದಾಗಿ ಹಂಚಿಕೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ಇಲ್ಲ ಇಲ್ಲ ಇಲ್ಲ. ಕ್ರ್ಯಾಶ್ ಖಾತರಿಯಿಲ್ಲ ಎಂದು ನಾನು ಹೇಳುತ್ತಿದ್ದೇನೆ. ಕೆಲವು ವಿನ್ಯಾಸ ವರ್ಗೀಕರಣಗಳು ಯಾವಾಗಲೂ ಕ್ರ್ಯಾಶ್ ಆಗುವುದಿಲ್ಲ.
