-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: Data-driven psychic power system #424
base: main
Are you sure you want to change the base?
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
There is still a crash with power_index going above power name array length.
a1aa35b
to
83e3552
Compare
@coderabbitai review |
📝 WalkthroughWalkthroughIn this sacred pull request, modifications have been enacted across several critical scripts that govern the mechanics of our digital realm. The initial alteration addresses the decrement of the Suggested labels
Suggested reviewers
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
objects/obj_ncombat/KeyPress_13.gml
(1 hunks)scripts/scr_add_artifact/scr_add_artifact.gml
(1 hunks)scripts/scr_perils_table/scr_perils_table.gml
(2 hunks)
🔇 Additional comments (5)
objects/obj_ncombat/KeyPress_13.gml (1)
94-95
:✅ Verification successful
Adjustment to the Perils reduction rate identified.
By the blessed calculation engines of the Omnissiah, I observe the modification of the decrement coefficient from 4 to 0.04 - a reduction of precisely 100 units. This alteration coordinates with the decimal-based Perils system modifications observed in scr_perils_table.gml, where increments now occur at 0.2 rather than 25.
Commence analysis to ensure Perils accumulation and reduction maintains appropriate equilibrium:
🏁 Script executed:
#!/bin/bash # Perform binary examination of psychic perils accumulation patterns # Seek additional references to global_perils to ensure consistent decimal usage rg -A 2 -B 2 "global_perils" --glob "*.gml"Length of output: 1442
Perils Reduction Rate Confirmed & Approved
The binary incantations confirm that our decimal-based rites have been properly enacted:
- KeyPress_13.gml (Lines 94-95): The global_perils now decrements by 0.04, harmonizing with the new standard.
- scr_perils_table.gml: The increment of global_perils is now set to 0.2, evidencing the conversion from the old integer-based system to our sacred decimal scale.
- scr_powers.gml: The integration of global_perils in perils_chance calculations aligns with these adjustments.
The machine spirits rejoice at the balance maintained across the codebase, and the adjustments meet the Omnissiah's precise calculations.
scripts/scr_perils_table/scr_perils_table.gml (1)
111-112
: Perils accumulation value altered to decimal representation.The Motive Force guides this change from integer incrementation (likely 25) to decimal incrementation (0.2). This modification aligns with the decimal reduction rate of 0.04 in obj_ncombat/KeyPress_13.gml, providing more granular control over the Perils of the Warp fluctuations.
scripts/scr_add_artifact/scr_add_artifact.gml (3)
160-162
: Artifact tagging logic now uses canonical Chaos god identifiers.The Machine Spirits will be pleased with this logical enhancement. The artifact tagging process now applies the uppercase Chaos god identifiers ("KHORNE", "NURGLE", "TZEENTCH", "SLAANESH") rather than numeric suffixes, which aligns with the modifications in scr_perils_table.gml and increases data coherence.
164-166
: Tome artifacts correctly exclude KHORNE from possible Chaos alignments.01001010 01110101 01100100 01100111 01100101 01100100 00100000 01100001 01100011 01100011 01110101 01110010 01100001 01110100 01100101
The logic correctly excludes the Blood God from tome artifacts, maintaining the lore-appropriate restriction that Khorne has no interest in psychic tomes or written knowledge. This is consistent with the established doctrine of the Adeptus Administratum.
161-164
:✅ Verification successful
Verify consistency of string concatenation across codebase.
The sacred cogitators observe that the string concatenation procedure here lacks a separator between "daemonic" and the Chaos god name. This could be intentional, but requires verification to ensure proper string parsing elsewhere in the code.
🏁 Script executed:
#!/bin/bash # Examine other string operations on daemonic artifacts # Search for parsing operations on daemonic artifacts rg "daemonic\w+" --glob "*.gml" # Search for code that checks artifact tags rg "artifact_tags.*daemonic" --glob "*.gml"Length of output: 961
Directive: Harmonized Daemonic Concatenation Confirmed
After communing with the machine spirit and examining the sacred logs, it is observed that the concatenation ritual—fusing "daemonic" directly with the Chaos god name—is executed uniformly across the codebase. The repository’s records (e.g., in the artifact tag examinations within Step_0.gml and related scripts) corroborate that the absence of a separator is an intentional design decree rather than a coding impurity.
• In scripts/scr_add_artifact.gml, the concatenation of "daemonic" with choose("NURGLE", "TZEENTCH", "SLAANESH") mirrors the consistent practice found in other artifacts.
• Artifact tag validations in Step_0.gml and Alarm_1.gml similarly adhere to the same sacred pattern.Thus, the ritual is sound. No alterations are required unless further stylistic clarifications are desired by the order.
May the Omnissiah bless your constructs.
@coderabbitai full review |
@coderabbitai summary |
✅ Actions performedSummary regeneration triggered. |
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
objects/obj_ncombat/KeyPress_13.gml
(1 hunks)scripts/scr_add_artifact/scr_add_artifact.gml
(1 hunks)scripts/scr_perils_table/scr_perils_table.gml
(2 hunks)
🔇 Additional comments (4)
objects/obj_ncombat/KeyPress_13.gml (1)
94-94
:✅ Verification successful
Calibration of perils decrement gradient adjusted to match new scaling system.
The modification of the decrement value from an assumed integer (4) to a decimal (0.04) indicates a 100-fold scaling adjustment in the perils system. This alteration allows for finer gradation and more precise control of the perils accumulation/dissipation cycle.
🏁 Script executed:
#!/bin/bash # Seek other instances of perils manipulation to verify consistent decimal scaling echo "Searching for all perils manipulations in the codebase..." rg "global_perils\s*[-+]=\s*\d+\.?\d*" -A 2 -B 2Length of output: 986
Attention, O Adept of the Sacred Code!
Your inspection has revealed that the perils scaling adjustments have indeed been enacted with decimal precision. The decrement of 0.04 in
objects/obj_ncombat/KeyPress_13.gml
stands in harmonious accord with the system-wide calibration, where decimal manipulations (such as the addition of 0.2 inscripts/scr_perils_table/scr_perils_table.gml
) ensure finer control over perils accumulation and dissipation.
- The updated decrement operation (
if (global_perils>0) then global_perils-=0.04;
) confirms the refined, 100-fold scaling adjustment.- The presence of similarly calibrated decimal operations elsewhere in the code confirms consistency across the repository.
May the Omnissiah bless your fusion of logic and precision. The machine spirits approve this adjustment.
scripts/scr_perils_table/scr_perils_table.gml (2)
143-145
: Daemon entity identification now uses canonical Chaos god identifiers.Praise be to the Omnissiah for this logical optimization. The daemon entity identification now employs uppercase string literals ("SLAANESH", "NURGLE", "TZEENTCH") rather than numeric identifiers, improving code semantics and thematic coherence. The binary efficiency of uppercase constants for string comparison is commendable.
111-111
:✅ Verification successful
Perils increment value recalibrated to decimal system.
The modification transforms the perils increment value from an integer (presumed 25) to a decimal (0.2). This adjustment is in accordance with the omniscient plan to implement a finer gradient scaling system (100-fold reduction), enhancing precision in warp fluctuation calculations.
🏁 Script executed:
#!/bin/bash # Verify consistent scaling in perils accumulation and dissipation echo "Confirming alignment of perils scaling across the codebase..." rg "global_perils\s*[-+]=\s*\d+\.?\d*" --sort pathLength of output: 353
Omnissiah’s Blessings: Decimal Calibration Verified
The recalibration of perils scaling to a refined decimal system has been confirmed. The increment inscripts/scr_perils_table/scr_perils_table.gml
now correctly employs a value of0.2
while the dissipation logic inobjects/obj_ncombat/KeyPress_13.gml
accurately subtracts0.04
. These sacred modifications align with the intentions of our finer gradient scaling, ensuring enhanced precision in warp fluctuation calculations.scripts/scr_add_artifact/scr_add_artifact.gml (1)
160-160
:✅ Verification successful
Standard artifacts now employ canonical Chaos god identifiers.
The artifact tagging algorithm has been optimized to utilize explicit Chaos god designations ("KHORNE", "NURGLE", "TZEENTCH", "SLAANESH") rather than numeric suffixes. This enhances both the machine-readability and thematic cohesion of the codebase.
🏁 Script executed:
#!/bin/bash # Verify consistent Chaos god naming across the codebase echo "Scanning for Chaos god references to ensure nomenclature consistency..." rg -i "khorne|nurgle|tzeentch|slaanesh" --sort pathLength of output: 15978
Chaos God Naming Update Approved
Glory to the Machine Spirit! The artifact tagging algorithm has been successfully reformed to employ the canonical identifiers ("KHORNE", "NURGLE", "TZEENTCH", "SLAANESH") as confirmed by the repository scan. The explicit naming now permeates the codebase—demonstrably in
scripts/scr_add_artifact/scr_add_artifact.gml
on line 160—enhancing both machine-readability and thematic cohesion. No further alterations are required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
objects/obj_pnunit/Alarm_0.gml
(1 hunks)scripts/scr_perils_table/scr_perils_table.gml
(4 hunks)scripts/scr_player_combat_weapon_stacks/scr_player_combat_weapon_stacks.gml
(1 hunks)
🔇 Additional comments (6)
scripts/scr_perils_table/scr_perils_table.gml (5)
2-2
: Invocation recognized, no issues foreseen.
This doc-style annotation fosters clarity. Continue employing such markings to enhance code comprehension.
50-50
: Safeguard the random index usage.
Summon caution whenmen
could be zero, lest we breach array boundaries. Consider verifyingmen > 0
before callingirandom(men)
.
106-106
: Reinforce indexing checks.
As with line 50, confirm thatmen
is suitably positive to avoid out-of-range access inmarine_type[t]
.
112-112
: Gradual warp influence acknowledged.
Incrementingglobal_perils
by 0.2 instead of 25 ensures a gentler escalation in warp effects.
144-146
: Maintain consistent daemonic naming approach.
Previous review suggested using macros or a constant array for daemonic references. Standardize naming to avoid confusion.scripts/scr_player_combat_weapon_stacks/scr_player_combat_weapon_stacks.gml (1)
170-185
: Scrutiny of psyker cast logic.
- Be wary of the single
=
usage for comparisons (e.g.,(marine_type[g]="Chapter Master")
), as it may act as an assignment in certain contexts.- The new random-based cast threshold looks sound, but ensure it aligns with the overall difficulty levels.
- The commented-out relic (“big_boom”, “kamehameha”) suggests legacy code. Remove or maintain with clarifying justification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 13
♻️ Duplicate comments (1)
objects/obj_pnunit/Alarm_0.gml (1)
18-19
:⚠️ Potential issuePurify comparisons by using “==” instead of “=“
In the sacred GML dialect,=
for equality checks channels the Warp’s unpredictability. Use==
for infallible logic.- if (obj_ncombat.defending=false) or (obj_ncombat.dropping=1){ + if (obj_ncombat.defending==false) or (obj_ncombat.dropping==1){
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (6)
objects/obj_enunit/Alarm_1.gml
(2 hunks)objects/obj_pnunit/Alarm_0.gml
(1 hunks)objects/obj_pnunit/Create_0.gml
(1 hunks)scripts/scr_json_functions/scr_json_functions.gml
(0 hunks)scripts/scr_perils_table/scr_perils_table.gml
(4 hunks)scripts/scr_player_combat_weapon_stacks/scr_player_combat_weapon_stacks.gml
(4 hunks)
💤 Files with no reviewable changes (1)
- scripts/scr_json_functions/scr_json_functions.gml
🧰 Additional context used
🧠 Learnings (1)
objects/obj_pnunit/Alarm_0.gml (1)
Learnt from: EttyKitty
PR: Adeptus-Dominus/ChapterMaster#424
File: objects/obj_pnunit/Alarm_0.gml:208-301
Timestamp: 2025-02-26T12:50:19.276Z
Learning: In GameMaker Language (GML), both `=` and `==` can be used for equality comparisons and the code will execute correctly. However, using `=` for comparisons is considered a bad practice. The preferred approach is to use `=` exclusively for assignments and `==` for equality comparisons to maintain code clarity.
🔇 Additional comments (21)
objects/obj_pnunit/Create_0.gml (1)
43-43
: Augment Access Array for Casting Cooldowns.
By introducingmarine_casting_cooldown
as an empty array, thou hast laid the foundation for tracking psionic skill usage and ensuring proper intervals between warp manipulations. Verify that each marine’s array index is properly assigned and remains within bounds when storing or retrieving cooldown values.objects/obj_enunit/Alarm_1.gml (2)
251-252
: Commented-Out Casting Reset Logic.
The removal ofmarine_casting[g] = false;
suggests that a separate script is now responsible for managing casting states. Ensure the new method consistently handles edge cases where marines remain stuck in a casting state if not properly reset elsewhere.
298-305
: Conditional Weapon Assignment With Casting Check.
Gating weapon additions behindif (marine_casting[g] == false)
cleanses the code of contradictory states, ensuring a marine in the midst of warp manipulations cannot simultaneously handle armaments. This is cogently aligned with the updated psionic flow. Maintain vigilance for any hidden concurrency among marines array.scripts/scr_player_combat_weapon_stacks/scr_player_combat_weapon_stacks.gml (3)
161-161
: Secondary Profile Integration for Mobility Items.
Invokingadd_second_profiles_to_stack(mobi_item);
provides synergy for items with layered capabilities. Confirm that future expansions do not introduce repeated infinite loops.
218-218
: Casting State Check.
Skipping ranged/melee assignment whenmarine_casting[g]
is true is prudent, preventing resource overlap. This fosters clarity between warp-crafting and direct combat.
339-340
: Initialization of Casting Arrays.
Addingmarine_casting
andmarine_casting_cooldown
to every new unit scaffolds robust psionic management. Ensure that new races or unique marine types also initialize these arrays properly for consistent usage.scripts/scr_perils_table/scr_perils_table.gml (10)
2-2
: Omnissiah Annotation Detected.
The/// @mixin
annotation suggests potential doc or introspection. Verify that the environment respects this directive and does not discard it in normal execution.
6-6
: Increment Cooldown by 2.
Invokingmarine_casting_cooldown[unit_id] += 2;
for mild psychic lash results in moderate extension of warp penalties. Such increments appear balanced, yet consider bounding extreme accumulations.
13-13
: Increment Cooldown by 3.
This adds a longer recharge for more severe mental backlash. Confirm synergy with line 6 so that repeated lash events do not push marines into perpetual inaction unless desired.
26-26
: Prolonged Ban on Casting.
Similarly,+= 999
ensures no further powers are invoked. Verify that no overshadowing logic re-enables casting prematurely.
32-32
: Extended Cooldown For Psychic Mishap.
Adding 3 tomarine_casting_cooldown[unit_id]
aligns with the fiery mishap penalty. Ensure a cohesive scale of warp penalties across all perils for consistent user experience.
52-52
: Minor Casting Delay.
And so+= 1
imposes a small penalty for a lesser mental disturbance. This is consistent with the established pattern; review to confirm these incremental steps form a balanced difficulty curve.
63-63
: Warp Disturbance – Medium Cooldown.
+= 2
for conjuring lesser daemons is suitable. Confirm consistent logic with lines 6 and 13 regarding moderate peril outcomes.
122-122
: Global Perils Increase With Smaller Delay.
A+= 1
tomarine_casting_cooldown
combined withobj_ncombat.global_perils += 0.2
spreads mild warp chaos. Confirm synergy with other increments to maintain overall consistency.
128-128
: Cataclysmic Shockwave.
By adding 999, the marine remains incapacitated for the conflict. This is consistent with your other severe outcomes.
155-157
: Canonical Chaos God Identifiers.
Blessed is the standardization of uppercase checks for “SLAANESH”, “NURGLE”, and “TZEENTCH.” Reusing the same approach from previous expansions fosters code uniformity.objects/obj_pnunit/Alarm_0.gml (5)
1-2
: Blessed insertion of exception containment
O revered disciple, thistry
block is a wise invocation that shields the code from runtime calamities. The Machine God smiles upon robust error handling.
4-4
: No immediate issues with initial variables
Your variables are consecrated in a single, clear line. Efficiency and clarity are upheld.
7-8
: Double-check object count condition
O Magos, ensure you intentionally seek outcomes only if one entity is absent. If there is but a single instance, the code path is altered. Consider verifying related conditions if your design demands otherwise.
22-24
: Admirable checks for missing or engaged foes
Exiting early if no worthy foes remain preserves the holy flow of logic. These lines stand well-blessed with clarity.
201-201
: Reactivating enemy objects
No objections—granting life anew to the foe ensures continuous conflict. The Omnissiah’s will be done.
scripts/scr_player_combat_weapon_stacks/scr_player_combat_weapon_stacks.gml
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
♻️ Duplicate comments (9)
objects/obj_pnunit/Alarm_0.gml (9)
60-60
:⚠️ Potential issueEquality operator heresy detected
Your code utilizes assignment operators where comparison is intended. The Omnissiah demands consistency in logical operations.
- if ((range[i]!=floor(range[i]) || floor(range[i])=1) && engaged=1) then range_shoot="melee"; + if ((range[i]!=floor(range[i]) || floor(range[i])==1) && engaged==1) then range_shoot="melee";
63-68
:⚠️ Potential issuePurify comparison operators in weapon identification logic
String comparison and logical evaluation rituals must maintain proper form to appease the machine spirits.
- if (range_shoot="ranged") and (range[i]>=dist){ + if (range_shoot=="ranged") and (range[i]>=dist){ - if (wep[i]="Missile Launcher") then ap=1; + if (wep[i]=="Missile Launcher") then ap=1; - if (instance_number(obj_enunit)=1) and (obj_enunit.men=0) and (obj_enunit.veh>0) then ap=1; + if (instance_number(obj_enunit)==1) and (obj_enunit.men==0) and (obj_enunit.veh>0) then ap=1;
74-74
:⚠️ Potential issueEquality transgressions detected in AP verification protocols
The binary evaluation sigil must be doubled for proper logical comparison.
- if (ap=1) and (once_only=0){ + if (ap==1) and (once_only==0){
81-95
:⚠️ Potential issueMultiple logical comparison deviations detected
Your conditional evaluations throughout this section use the forbidden single-equals notation. Rectify to maintain consistency with machine doctrine.
- if (good=0) and (instance_number(obj_enunit)>1){ + if (good==0) and (instance_number(obj_enunit)>1){ - if (good=0){ + if (good==0){ - if (enemy2.veh>0) and (good=0){ + if (enemy2.veh>0) and (good==0){ - if (good=0) then ap=0; + if (good==0) then ap=0;Additionally, the comment on line 95 employs language unbefitting of a sacred machine text. Consider a more appropriate phrasing.
104-124
:⚠️ Potential issueHeretical equality sigils persist in medic targeting routines
The machine spirits require purification of comparison operators throughout this segment.
- if (instance_exists(enemy)) and (once_only=0){ + if (instance_exists(enemy)) and (once_only==0){ - if (enemy.medi>0) and (enemy.veh=0){ + if (enemy.medi>0) and (enemy.veh==0){ - if (good=0) and (instance_number(obj_enunit)>1){ + if (good==0) and (instance_number(obj_enunit)>1){ - if (good=0){ + if (good==0){ - if (enemy2.veh>0) and (good=0){ + if (enemy2.veh>0) and (good==0){ - if (good=0) then ap=0; + if (good==0) then ap=0;
131-151
:⚠️ Potential issueRectify comparison operations in infantry targeting logic
The Machine Cult demands consistency in logical evaluations.
- if (ap=0) and (once_only=0){ + if (ap==0) and (once_only==0){ - if (good=0) and (instance_number(obj_enunit)>1){ + if (good==0) and (instance_number(obj_enunit)>1){ - if (good=0){ + if (good==0){ - if (enemy2.men>0) and (good=0){ + if (enemy2.men>0) and (good==0){
152-169
:⚠️ Potential issueEquality sigil deficiencies in melee engagement protocols
The sacred machine code requires purification of comparison operators.
- else if (range_shoot="melee") and ((range[i]==1) or (range[i]!=floor(range[i]))){ + else if (range_shoot=="melee") and ((range[i]==1) or (range[i]!=floor(range[i]))){ - if (enemy.men=0) and (apa[i]=0) and (att[i]>=80){ + if (enemy.men==0) and (apa[i]==0) and (att[i]>=80){ - if (apa[i]==1) and (once_only=0){ + if (apa[i]==1) and (once_only==0){ - if (range[i]=1) then scr_shoot(i,enemy,good,"arp","melee"); + if (range[i]==1) then scr_shoot(i,enemy,good,"arp","melee"); - if (good=0) and (att[i]>0) then ap=0; + if (good==0) and (att[i]>0) then ap=0;
171-180
:⚠️ Potential issueLogical comparison errors in medic engagement protocols
Binary evaluation consistency violations detected throughout this segment.
- if (enemy.veh=0) and (enemy.medi>0) and (once_only=0){ + if (enemy.veh==0) and (enemy.medi>0) and (once_only==0){ - if (range[i]=1) then scr_shoot(i,enemy,good,"medi","melee"); + if (range[i]==1) then scr_shoot(i,enemy,good,"medi","melee"); - if (good=0) and (att[i]>0) then ap=0; + if (good==0) and (att[i]>0) then ap=0;
184-193
:⚠️ Potential issueLogical inconsistencies in final target engagement protocols
Purge the impure assignment operators used in comparison contexts.
- if (ap=0) and (once_only=0){ + if (ap==0) and (once_only==0){ - if (enemy.men>0) and (once_only=0){ + if (enemy.men>0) and (once_only==0){ - if (range[i]=1) then scr_shoot(i,enemy,good,"att","melee"); + if (range[i]==1) then scr_shoot(i,enemy,good,"att","melee");
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
objects/obj_enunit/Alarm_1.gml
(2 hunks)objects/obj_pnunit/Alarm_0.gml
(1 hunks)scripts/scr_powers_new/scr_powers_new.gml
(2 hunks)
🧰 Additional context used
🧠 Learnings (1)
objects/obj_pnunit/Alarm_0.gml (2)
Learnt from: EttyKitty
PR: Adeptus-Dominus/ChapterMaster#424
File: objects/obj_pnunit/Alarm_0.gml:203-299
Timestamp: 2025-02-26T14:38:08.117Z
Learning: Variable shadowing/overshadowing (reusing the same variable name in nested scopes, particularly loop iterators) should be flagged as a critical issue, not a nitpick, as it can cause unpredictable behavior, bugs that are difficult to trace, and potential crashes.
Learnt from: EttyKitty
PR: Adeptus-Dominus/ChapterMaster#424
File: objects/obj_pnunit/Alarm_0.gml:208-301
Timestamp: 2025-02-26T12:50:19.276Z
Learning: In GameMaker Language (GML), both `=` and `==` can be used for equality comparisons and the code will execute correctly. However, using `=` for comparisons is considered a bad practice. The preferred approach is to use `=` exclusively for assignments and `==` for equality comparisons to maintain good code style.
🔇 Additional comments (6)
objects/obj_enunit/Alarm_1.gml (3)
258-264
: Documentation of the sacred function parameters preserved.The Machine Spirit approves of the preserved documentation for the
scr_en_weapon
function. Such annotations serve as devotional rites to ensure future tech-adepts comprehend the machine's purpose.
305-305
: Logical consistency maintained with boolean comparison.The same boolean condition optimization has been consistently applied in this instance as well. The Machine Spirit values such consistency.
251-252
:✅ Verification successful
Logical observation on variable removal, adept.
The removal of the variable initialization
marine_casting[g] = 0
appears prudent if it was indeed redundant. However, the Omnissiah demands certainty - confirm that this variable is properly initialized elsewhere in the machine spirit's code to prevent undefined behavior.
🏁 Script executed:
#!/bin/bash # Searching for marine_casting initialization or declaration in the codebase echo "Searching for marine_casting initialization patterns..." rg -A 3 "marine_casting\s*=\s*(0|false)" --glob "*.gml" rg -A 3 "marine_casting\[\w+\]\s*=\s*(0|false)" --glob "*.gml" echo "Checking for array declaration patterns..." rg "marine_casting\s*=\s*\[\]" --glob "*.gml" rg "marine_casting\s*=\s*array_create" --glob "*.gml"Length of output: 1216
Initialization of the marine_casting array verified, O Faithful Codex-holder
The Machine Spirit confirms that the marine_casting array is properly instantiated in
objects/obj_pnunit/Create_0.gml
with the declarationmarine_casting = [];
. Additionally, assignment operations—such as settingmarine_casting[g] = false
inscripts/scr_player_combat_weapon_stacks.gml
—reveal that the index values receive their fidelity elsewhere in the code. Thus, the removal of the now redundant initialization inobjects/obj_enunit/Alarm_1.gml
is in accordance with the Omnissiah’s will.May you continue your endeavors with the blessings of the Machine Spirit, and verify that all indices receive their due liturgical assignments prior to invocation.
scripts/scr_powers_new/scr_powers_new.gml (2)
29-33
: Binary constraint adjustments detectedThe code has modified the upper boundaries of psychic power acquisition from
letmax+1
toletmax
, and adjusted the random power selection fromfloor(random(letmax))+1
tofloor(random(letmax))
. This harmonizes with the data-driven approach mentioned in the sacred scrolls of the PR description.
44-50
: Logical constraints realignedThe Machine Spirit approves of these systematic boundary adjustments. The modification from
powers_have<(letmax+1)
topowers_have<(letmax)
ensures consistent enforcement of psychic limitations across all codepaths.objects/obj_pnunit/Alarm_0.gml (1)
1-307
: Commendable implementation of the Omnissiah's protection protocolsThe encapsulation of combat logic within try-catch blocks represents proper veneration of machine-spirit integrity. Error states are now properly captured and channeled to the
handle_exception
ritual instead of causing catastrophic system failure.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
objects/obj_pnunit/Alarm_0.gml
(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
objects/obj_pnunit/Alarm_0.gml (2)
Learnt from: EttyKitty
PR: Adeptus-Dominus/ChapterMaster#424
File: objects/obj_pnunit/Alarm_0.gml:203-299
Timestamp: 2025-02-26T14:38:08.117Z
Learning: Variable shadowing/overshadowing (reusing the same variable name in nested scopes, particularly loop iterators) should be flagged as a critical issue, not a nitpick, as it can cause unpredictable behavior, bugs that are difficult to trace, and potential crashes.
Learnt from: EttyKitty
PR: Adeptus-Dominus/ChapterMaster#424
File: objects/obj_pnunit/Alarm_0.gml:208-301
Timestamp: 2025-02-26T12:50:19.276Z
Learning: In GameMaker Language (GML), both `=` and `==` can be used for equality comparisons and the code will execute correctly. However, using `=` for comparisons is considered a bad practice. The preferred approach is to use `=` exclusively for assignments and `==` for equality comparisons to maintain good code style.
🔇 Additional comments (1)
objects/obj_pnunit/Alarm_0.gml (1)
300-308
: Commendable try-catch structure.
Your use oftry { } catch(...)
admirably protects the engine from runic catastrophes. May the Omnissiah keep you in His favor for such diligence.
Purpose of the PR
Describe the solution
Testing done
Related links