fix: General Code Refactoring #1081
Conversation
…intained versions, and whitespace in touched files normalized.
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughCode Review AnalysisWalkthroughThe pull request contains formatting corrections, control flow improvements, and substantial refactoring of combat and equipment mechanics. Changes include fixed conditional structures, effect rendering adjustments using depth-based functions, enhanced targeting and weapon systems, and consolidated armour/equipment validation logic across multiple game objects. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~65 minutes Possibly related PRs
Suggested labels
Suggested reviewers
The machine spirits whisper of logic reformed and weapons perfected, Tech-Priest. Yet shadows linger—scrutinise the assignment within the tyranid vessel most carefully. The depths have shifted in ways that demand vigilance. Pre-merge checks❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 16
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (9)
objects/obj_en_ship/Alarm_0.gml (2)
1309-1311: Expunge the debug constructs from the data stream.The profane markers of unfinished development persist within lines 1309 and 1311. The hardcoded identifier "sdagdsagdasg" overrides all ship designation protocols, whilst the commented ork naming routine lies dormant—neither active nor removed. These artifacts must be excised entirely. The placeholder designation shall corrupt the vessel's proper nomenclature should it persist.
Purge both abominations: the commented logic and the hardcoded string. Should the ork naming feature require future resurrection, an appropriate sanctification (separate issue) may be issued.
1078-1078: Indexing anomaly confirmed in weaponry array.The cooldown binding for the secondary armament is incorrectly assigned. Within the
weapon[2]definition block,weapon_cooldown[1]=30must be corrected toweapon_cooldown[2]=30. All other weapon properties in this block correctly reference index 2.objects/obj_al_ship/Alarm_0.gml (3)
871-871: Heretical data signature detected, Tech-Priest.An unauthorized designation string pollutes the vessel nomenclature. This debug remnant must be purged from the sacred code before deployment to the materium.
🔎 Sanctioned purification ritual
-name="sdagdsagdasg";If this inscription serves a testing purpose, it must be rendered inert through commenting or conditional activation.
7-7: Ancient parchment of intent discovered, Tech-Priest.The TODO inscription speaks of transmuting these vessel configurations into dictionary or constructor forms. This architectural reformation would serve the Machine Spirit well.
Shall the Tech-Priest require the Machine Spirit to inscribe a tracking rune (GitHub issue) for this sacred task?
8-846: Extensive replication detected within the sacred texts, Tech-Priest.The vessel configuration patterns exhibit significant duplication across all faction doctrines. The TODO inscription at Line 7 acknowledges this technical debt. A data-driven architecture—wherein ship configurations reside within external data structures—would honour the DRY principle and simplify maintenance rituals.
Based on learnings, this refactoring is acknowledged by the Adeptus Mechanicus but deferred to future work beyond the scope of this purification ritual.
objects/obj_al_ship/Step_0.gml (2)
481-482: CRITICAL DATA CORRUPTION: Assignment operator taints faction comparisons, Tech-Priest.These lines employ
=(assignment) where==(comparison) is required. This heresy shall overwrite theownervariable with faction values, corrupting the ship's allegiance mid-combat and causing cascading logic failures.
- Line 481:
if (owner = eFACTION.Tyranids)assigns Tyranids to owner- Line 482:
if (owner = eFACTION.Tau) or (owner = eFACTION.Eldar)assigns Tau, then Eldar🔧 Prescribed remedy
- if (owner = eFACTION.Tyranids) then bull.sprite_index=spr_glob; - if (owner = eFACTION.Tau) or (owner = eFACTION.Eldar) then bull.sprite_index=spr_pulse; + if (owner == eFACTION.Tyranids) then bull.sprite_index=spr_glob; + if (owner == eFACTION.Tau) or (owner == eFACTION.Eldar) then bull.sprite_index=spr_pulse;
610-615: The same corruption manifests here, Tech-Priest.Lines 610 and 615 bear the same affliction:
owner = eFACTION.Eldarperforms assignment rather than comparison.🔧 Prescribed remedy
- if (string_count("Weapons",wep)==1) and (owner = eFACTION.Eldar){ + if (string_count("Weapons",wep)==1) and (owner == eFACTION.Eldar){ bull.sprite_index=spr_ground_las; bull.image_xscale=2; bull.image_yscale=2; } - if (string_count("Pulse",wep)==1) and (owner = eFACTION.Eldar){ + if (string_count("Pulse",wep)==1) and (owner == eFACTION.Eldar){ bull.sprite_index=spr_pulse;objects/obj_mass_equip/Step_0.gml (1)
310-317: Potential null dereference lurks within, Tech-Priest.Should
unit.get_armour_data()returnundefinedor a non-struct value (for unarmoured units or error states), the invocation of.has_tag("terminator")shall trigger a fatal exception.Contrast this with line 79, where
is_struct(unit_armour)guards the call. The same protection is warranted here.🔧 Prescribed remedy
function can_assign_weapon(unit, weapon_name) { switch (weapon_name) { case "Assault Cannon": - return unit.get_armour_data().has_tag("terminator"); + var armour_data = unit.get_armour_data(); + return is_struct(armour_data) && armour_data.has_tag("terminator"); default: return true; } }objects/obj_al_ship/Draw_0.gml (1)
20-28: The shield display logic requires correction, Tech-Priest.The conditional guard examines
maxhp != 0, yet the calculation divides bymaxshields. Whilst the initialisation protocols establish thatmaxshieldsshall never be zero when shields manifest (being set to positive values in both Create_0 and paired with shields in Alarm_0), the guard condition itself is logically misaligned. For code clarity and robustness, the guard should verifymaxshields != 0rather thanmaxhp != 0when performing this division.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (11)
objects/obj_al_ship/Alarm_0.gmlobjects/obj_al_ship/Draw_0.gmlobjects/obj_al_ship/Step_0.gmlobjects/obj_en_ship/Alarm_0.gmlobjects/obj_en_ship/Draw_0.gmlobjects/obj_en_ship/Step_0.gmlobjects/obj_mass_equip/Draw_0.gmlobjects/obj_mass_equip/Step_0.gmlobjects/obj_p1_bullet/Collision_obj_ork.gmlscripts/__global_object_depths/__global_object_depths.gmlscripts/object_get_depth/object_get_depth.gml
🧰 Additional context used
📓 Path-based instructions (2)
**/*.gml
⚙️ CodeRabbit configuration file
**/*.gml: - Constants ofmacrotype MUST have a space between the constant name and its value. Without it, the compiler will throw an error.
- WRONG:
#macro COLOR_RED11119- RIGHT:
#macro COLOR_RED 11119- Color codes in the code SHOULDN'T have any spaces in their ID.
- WRONG:
# 80bf40- RIGHT:
#80bf40- All code should comply with the up-to-date GML documentation.
Files:
objects/obj_al_ship/Alarm_0.gmlscripts/__global_object_depths/__global_object_depths.gmlobjects/obj_en_ship/Step_0.gmlobjects/obj_en_ship/Draw_0.gmlobjects/obj_en_ship/Alarm_0.gmlobjects/obj_al_ship/Draw_0.gmlobjects/obj_mass_equip/Step_0.gmlobjects/obj_al_ship/Step_0.gmlobjects/obj_mass_equip/Draw_0.gmlscripts/object_get_depth/object_get_depth.gmlobjects/obj_p1_bullet/Collision_obj_ork.gml
**/*.*
⚙️ CodeRabbit configuration file
**/*.*: - Do not prioritize the shortest code. Prioritize code that explicitly reveals its intent.
- Understandable variable naming is extremely important.
- If a solution is "clever" but hard to parse mentally, request a refactor to a more verbose but clearer approach.
- Apply the "Rule of Three": suggest abstraction when logic is repeated three times or more times.
- For subjective improvements (naming, architectural choice), do not give a concrete suggestion immediately. Instead, ask a guiding question to prompt the user's reflection.
- Every suggestion for a code change must include a brief justification.
- If a TODO comment is added, ask the user if you should create a GitHub issue for this TODO.
- If a TODO comment is deleted, remind the user if there is an active GitHub issue related to that comment.
Files:
objects/obj_al_ship/Alarm_0.gmlscripts/__global_object_depths/__global_object_depths.gmlobjects/obj_en_ship/Step_0.gmlobjects/obj_en_ship/Draw_0.gmlobjects/obj_en_ship/Alarm_0.gmlobjects/obj_al_ship/Draw_0.gmlobjects/obj_mass_equip/Step_0.gmlobjects/obj_al_ship/Step_0.gmlobjects/obj_mass_equip/Draw_0.gmlscripts/object_get_depth/object_get_depth.gmlobjects/obj_p1_bullet/Collision_obj_ork.gml
🧠 Learnings (11)
📓 Common learnings
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 647
File: scripts/scr_en_weapon/scr_en_weapon.gml:24-928
Timestamp: 2025-03-29T10:30:25.598Z
Learning: A data-driven approach for weapon management in `scripts/scr_en_weapon/scr_en_weapon.gml` is planned for a future PR, not within the scope of PR #647.
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 0
File: :0-0
Timestamp: 2025-04-05T20:58:21.881Z
Learning: In the ChapterMaster game, there's a need to refactor hardcoded item effects and move them to a "specials" property of items, following the pattern established with the `combi_tool` special. This improves code maintainability and makes effects more explicit in item definitions.
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 0
File: :0-0
Timestamp: 2025-04-05T20:58:21.881Z
Learning: In the ChapterMaster game, there's a need to refactor hardcoded item effects and move them to a "specials" property of items, following the pattern established with the `combi_tool` special. This improves code maintainability and makes effects more explicit in item definitions.
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 0
File: :0-0
Timestamp: 2025-03-20T22:22:57.319Z
Learning: In the ChapterMaster game PR #424, the combat log was expanded to display up to 24 messages instead of 8, providing more detailed battle information.
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 878
File: scripts/scr_culture_visuals/scr_culture_visuals.gml:1256-1352
Timestamp: 2025-06-16T17:12:13.045Z
Learning: In scripts/scr_culture_visuals/scr_culture_visuals.gml, the weapon visual data declarations contain known DRY violations that are acknowledged by the development team but deferred to future refactoring efforts rather than addressed in individual feature PRs.
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 878
File: scripts/scr_culture_visuals/scr_culture_visuals.gml:1256-1352
Timestamp: 2025-06-16T17:12:13.045Z
Learning: In scripts/scr_culture_visuals/scr_culture_visuals.gml, the weapon visual data declarations contain known DRY violations that are acknowledged by the development team but deferred to future refactoring efforts rather than addressed in individual feature PRs.
📚 Learning: 2025-03-31T23:32:30.003Z
Learnt from: OH296
Repo: Adeptus-Dominus/ChapterMaster PR: 646
File: objects/obj_pnunit/Alarm_5.gml:84-91
Timestamp: 2025-03-31T23:32:30.003Z
Learning: In obj_pnunit/Alarm_5.gml, the function get_armour_data("maintenance") will always return a numeric value (at minimum 0), making null/undefined checks unnecessary.
Applied to files:
objects/obj_al_ship/Alarm_0.gmlobjects/obj_en_ship/Draw_0.gmlobjects/obj_en_ship/Alarm_0.gmlobjects/obj_mass_equip/Step_0.gml
📚 Learning: 2025-03-07T01:56:40.971Z
Learnt from: MCPO-Spartan-117
Repo: Adeptus-Dominus/ChapterMaster PR: 562
File: scripts/scr_marine_struct/scr_marine_struct.gml:0-0
Timestamp: 2025-03-07T01:56:40.971Z
Learning: Marines' ages should be incremented at the year transition in obj_turn_end/Alarm_1.gml rather than calculated dynamically based on the current year and recruitment date. This ensures proper aging without retroactive application.
Applied to files:
objects/obj_al_ship/Alarm_0.gml
📚 Learning: 2025-03-29T10:30:25.598Z
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 647
File: scripts/scr_en_weapon/scr_en_weapon.gml:24-928
Timestamp: 2025-03-29T10:30:25.598Z
Learning: A data-driven approach for weapon management in `scripts/scr_en_weapon/scr_en_weapon.gml` is planned for a future PR, not within the scope of PR #647.
Applied to files:
objects/obj_al_ship/Alarm_0.gmlobjects/obj_en_ship/Step_0.gmlobjects/obj_mass_equip/Step_0.gml
📚 Learning: 2025-09-04T14:37:58.773Z
Learnt from: CR
Repo: Adeptus-Dominus/ChapterMaster PR: 0
File: docs/CODE_STYLE.md:0-0
Timestamp: 2025-09-04T14:37:58.773Z
Learning: Applies to docs/**/*.gml : Initialize variables when declaring them (e.g., var x = 0)
Applied to files:
scripts/__global_object_depths/__global_object_depths.gml
📚 Learning: 2025-03-31T15:41:45.611Z
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 649
File: objects/obj_enunit/Alarm_0.gml:289-291
Timestamp: 2025-03-31T15:41:45.611Z
Learning: GameMaker Studio's function `action_if_variable(image_index, -500, 0)` is auto-generated code from GameMaker's visual Drag and Drop system. It checks if image_index equals -500. In ChapterMaster, this was being used as a special flag for enemy unit movement, but wasn't triggering consistently, causing enemies to move only every other turn. The refactored code replaced this with direct function calls at specific combat stages.
Applied to files:
objects/obj_en_ship/Draw_0.gmlobjects/obj_al_ship/Step_0.gml
📚 Learning: 2025-03-31T15:41:45.611Z
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 649
File: objects/obj_enunit/Alarm_0.gml:289-291
Timestamp: 2025-03-31T15:41:45.611Z
Learning: GameMaker Studio's function `action_if_variable(image_index, -500, 0)` was part of an old enemy movement system in ChapterMaster. This syntax is auto-generated from GameMaker's Drag-and-Drop interface and checks if image_index is greater than or equal to -500. In the refactored code, enemy movement is triggered directly through function calls rather than relying on this conditional check.
Applied to files:
objects/obj_en_ship/Draw_0.gmlobjects/obj_al_ship/Step_0.gml
📚 Learning: 2025-06-16T17:12:13.045Z
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 878
File: scripts/scr_culture_visuals/scr_culture_visuals.gml:1256-1352
Timestamp: 2025-06-16T17:12:13.045Z
Learning: In scripts/scr_culture_visuals/scr_culture_visuals.gml, the weapon visual data declarations contain known DRY violations that are acknowledged by the development team but deferred to future refactoring efforts rather than addressed in individual feature PRs.
Applied to files:
objects/obj_mass_equip/Step_0.gml
📚 Learning: 2025-04-05T20:58:21.881Z
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 0
File: :0-0
Timestamp: 2025-04-05T20:58:21.881Z
Learning: In the ChapterMaster game, there's a need to refactor hardcoded item effects and move them to a "specials" property of items, following the pattern established with the `combi_tool` special. This improves code maintainability and makes effects more explicit in item definitions.
Applied to files:
objects/obj_mass_equip/Step_0.gml
📚 Learning: 2025-04-15T10:54:19.720Z
Learnt from: VanWeapon
Repo: Adeptus-Dominus/ChapterMaster PR: 725
File: scripts/scr_special_view/scr_special_view.gml:49-49
Timestamp: 2025-04-15T10:54:19.720Z
Learning: In the ChapterMaster codebase, obj_ini.role[100][2] and obj_ini.role[100][eROLE.ChapterMaster] reference different roles, and both are needed in conditions checking for specific types of units. Numeric indices should not be assumed to match their corresponding enum values without verification.
Applied to files:
objects/obj_mass_equip/Step_0.gml
📚 Learning: 2025-04-16T09:51:55.065Z
Learnt from: EttyKitty
Repo: Adeptus-Dominus/ChapterMaster PR: 0
File: :0-0
Timestamp: 2025-04-16T09:51:55.065Z
Learning: In obj_ingame_menu/Step_0.gml, the line "if (effect=14){instance_create(0,0,obj_fade);fading=0.1;}" must not be commented out, as it's critical for menu button transitions. When clicking the Exit button, it sets effect=14, but without this handler creating the fade effect object, no transition occurs.
Applied to files:
objects/obj_al_ship/Step_0.gmlobjects/obj_mass_equip/Draw_0.gmlobjects/obj_p1_bullet/Collision_obj_ork.gml
🔇 Additional comments (16)
objects/obj_en_ship/Alarm_0.gml (2)
1094-1097: Sanctioned: Braces contain the conditional logic most adequately.The addition of explicit braces around the conditional block demonstrates proper code discipline and aligns with structured control flow requirements.
15-19: The formatting refinements are deemed acceptable by the Omnissiah's standards.Whitespace normalizations, sprite assignment relocations, and structural indentation adjustments throughout the ship class initialisation blocks impose no functional corruption upon the game state. The code logic remains unaltered—thy semantics are preserved.
The broad conformity to visual parsing conventions shall ease future maintenance protocols.
Also applies to: 61-64, 101-104, 140-143, 171-174, 217-220, 250-253, 290-293, 322-325, 373-376, 427-429, 471-474, 525-528, 560-563, 607-610, 654-657, 701-704, 734-737, 770-773, 821-824, 854-857, 897-900, 926-929, 971-974, 1010-1013, 1049-1052, 1115-1118, 1154-1157, 1193-1196, 1220-1223, 1247-1250
objects/obj_al_ship/Alarm_0.gml (2)
45-45: The conditional chains have been sanctified, Tech-Priest.The transformation from standalone
elseblocks toelse ifbranches aligns with proper control flow doctrine. The Machine Spirit approves this structural refinement.Also applies to: 77-77, 98-98, 154-154, 180-180, 212-212, 277-277, 321-321, 355-355, 399-399, 466-466, 503-503, 541-541, 566-566, 637-637, 698-698, 758-758, 789-789, 820-820
120-120: The sacred separators have been inscribed, Tech-Priest.These demarcations between faction configurations enhance the ritual's legibility. The Machine Spirit finds this ordering acceptable.
Also applies to: 234-234, 426-426, 594-594, 720-720
objects/obj_mass_equip/Draw_0.gml (1)
28-28: The Rites of Depth Rendering are properly observed, Tech-Priest.The transition from
effect_create_abovetoeffect_create_depth(-15000, ...)aligns with the sacred deprecation protocols. The depth value of -15000 shall ensure the firework effect renders above the UI layer as intended.objects/obj_al_ship/Draw_0.gml (1)
7-11: Formatting rituals observed, Tech-Priest.The whitespace normalization follows the sacred patterns. The machine spirit detects no deviation from intended function.
objects/obj_p1_bullet/Collision_obj_ork.gml (2)
22-22: The sacred transition is complete, Tech-Priest.The deprecated
effect_create_abovefunction has been purged and replaced witheffect_create_depth(-15000, ...). The victory firework shall render at the ordained depth layer.
55-55: Consistency in the rites is maintained.This invocation mirrors the pattern established above. The machine spirit approves this uniformity in depth-based effect rendering.
objects/obj_en_ship/Draw_0.gml (1)
3-6: The structural braces are acceptable, Tech-Priest.The reformatting with explicit braces and parenthesized conditions improves clarity. The machine spirit observes no functional deviation.
scripts/__global_object_depths/__global_object_depths.gml (1)
192-192: The deprecated incantation has been purified, Tech-Priest.
array_length_1dhas been exorcised and replaced witharray_length, as ordained by the GameMaker 2.3+ Machine Codex. The sacred array bounds shall be computed correctly.scripts/object_get_depth/object_get_depth.gml (1)
5-11: The function has been cleansed and reformatted, Tech-Priest.The transition from
array_length_1dtoarray_lengthmaintains consistency with the global depths script. The logic remains pure: bounds verification followed by depth retrieval. The machine spirit is satisfied.objects/obj_al_ship/Step_0.gml (1)
58-58: The Tyranid death effect rendering is sanctified, Tech-Priest.The depth-based effect invocation shall ensure the firework renders at the proper layer upon bio-ship destruction.
objects/obj_mass_equip/Step_0.gml (3)
23-54: The armour validation logic is well-structured, Tech-Priest.The switch-case pattern for handling
STR_ANY_POWER_ARMOURandSTR_ANY_TERMINATOR_ARMOURtags is clear and maintainable. The fallback mechanism from Power Armour to Terminator is a prudent safeguard.
56-74: The weapon assignment logic is fortified, Tech-Priest.The introduction of
can_assign_weaponas a gatekeeper for weapon compatibility demonstrates sound defensive programming. The machine spirit approves this abstraction.
76-84: The mobility item logic is guarded correctly.The
is_struct(unit_armour)check before invokinghas_tags()prevents null reference corruption. This pattern should be mirrored elsewhere.objects/obj_en_ship/Step_0.gml (1)
20-27: The Omnissiah approves this targeting logic, Tech-Priest.The multi-source targeting system correctly discerns the nearest threat from both
obj_p_shipandobj_al_ship. The sacred logic flows true. However, consider whether line 26 might employ anelseclause rather than a redundant conditional check, for the Machine Spirit favours efficiency.
… overriden by the global luck enum. luck enum renamed to eLUCK, matching CODE_STYLE.md suggestion. Space Marine Luck stat potentially not working (properly) in past builds due to this overriding.
… empty function instead of a string.
… out for review of if they are meant to be reachable before the return statement, or if they can simply be deleted. Though the one unreachable return line could probably be safely deleted.
OH296
left a comment
OH296
left a comment
There was a problem hiding this comment.
Yeah seems legit i would argue that an overabundance of of line incrementing in nested areas is a PITA and would be better if it can be avoided if the autoformatter used can be adjusted.
Otherwise there are areas that can whole sale be avoided with regard to anything ship related it will only get deleted later and is a waste of time due to #312
| @@ -1,64 +1,108 @@ | |||
|
|
|||
There was a problem hiding this comment.
legacy object not used in code
There was a problem hiding this comment.
Could that entire object folder "New Ground" be removed?
purpose is to update table to correct base positions if initialised via dataa being passed dddirectly into constructor call needs to be placed after update static assignment in case update is not manually called on table later in the draw phase |
That's what i figured after looking over similar code and I added it to my little list of things to look into correcting. But it's easy enough to just go ahead and do now. |
… project and I don't see anything wrong with it?
…ed to be eGOD_MISSION according to CODE_STYLE.md
…leared out a slew of minor logic bugs just sitting in the code.
carys-the-weed-cloud
changed the title
… with an array of strings!
… jsdoc is saying. The jsdoc in this case was wrong based on the operation of role_groups().
…e will get confused on if you are using a local var or a generic core library function.
…keyword 'noone' so that you are able to read through and see that it's an instance not another type of variable.
…h according to yoyo are basically temp things to help your code transition from GM1 to GM2. We are far past that point and these can be replaced with native functions that don't scare you when you try to comprehend them.
…gic numbers. Beyond improving code readability, this also results in multiple bug fixes with the wrong data being assigned to the wrong faction. Nowhere near done because this touches a large part of the codebase.
…ons inherited from gamemaker 1.0 and replacing them with engine calls instead of the accursed custom ones whatever converter was used way back in the DAOT. May the omnissiah bless this holy rite of cleansing.
…rors. Some of these are simply good programming habit related, some make the code more readable, and others fix edge cases and improve logical consistency.
…etically result in further improvements to stability.
…le shtick of GM1041 errors. I have been calling them errors because thats what i have the gm editors warning error setting and its useful to see when data might be getting dropped accidentally, or needs a more graceful (and readable) conversion.
3 participants
Hi, I joined the discord and got to talking to some folks about how i would like to clear out the error/warning/suggestion log of the gamemaker project. Nobody objected, and I saw no reason to hesitate, so I am going to just open this PR, and as I commit changes people are free to discuss them and point out things they think are superfluous on my part.
None of my changes will add, remove, or modify functionality except in the case that changing the functionality of a line/block of code will fix a bug, and those will always be seperate commits from general code appearance cleanups.
Purpose and Description
Testing done
Related things and/or additional context