• BasicStructures.h (3 hunks)
• CCINIClass.h (1 hunks)
• CellClass.h (3 hunks)
• Dir.h (5 hunks)
• DisplayClass.h (2 hunks)
• EBolt.h (1 hunks)
• Facing.h (2 hunks)
• HouseClass.h (2 hunks)
• Kamikaze.h (1 hunks)
• MessageListClass.h (1 hunks)
• ObjectClass.h (2 hunks)
• SpawnManagerClass.h (1 hunks)
• StaticInits.cpp (1 hunks)
• Surface.h (7 hunks)
• TechnoClass.h (7 hunks)
• TechnoTypeClass.h (1 hunks)
• WeaponTypeClass.h (1 hunks)
• YRMathVector.h (7 hunks)

Kamikaze.h (1)

• 16-16: Change to AbstractClass* for Cell member in KamikazeControl struct is approved. Enhances flexibility in target handling for kamikaze missions.

EBolt.h (2)

• 8-8: Addition of include directive for ArrayClasses.h is approved. Prepares file for enhanced functionality.
• 10-10: Declaration of TechnoClass is approved. Indicates interaction with game entities for electric bolts.

SpawnManagerClass.h (1)

• 105-106: Renaming of members in SpawnManagerClass improves clarity. Target to Destination and NewTarget to Target make their roles more intuitive.

Facing.h (1)

• 28-28: Removal of explicit specifier from FacingClass constructor and addition of clarifying comments are approved. Enhances usability and code clarity.

WeaponTypeClass.h (1)

• 41-52: Addition of new methods for calculating speed and a static method for speed calculation in WeaponTypeClass is approved. Enhances flexibility and accuracy of weapon interactions.

MessageListClass.h (1)

• 86-88: Addition of a new PrintMessage method with a pLabel parameter and adjustments to existing methods in MessageListClass is approved. Improves messaging system flexibility and UI.

BasicStructures.h (3)

• 44-48: Addition of a boolean operator to ColorStruct is approved. Simplifies truthiness checks.
• 53-62: Introduction of a Colors namespace with predefined color constants is approved. Enhances usability and readability.
• 176-179: Addition of an IsEmpty() method to RectangleStruct is approved. Provides a straightforward way to check for default-initialized instances.

Dir.h (2)

• 14-15: Refinement of DirStruct constructors and methods in Dir.h is approved. Improves precision and flexibility of direction handling.
• 55-72: Introduction of new functions for value manipulation in DirStruct is approved. Provides additional tools for working with direction values.

DisplayClass.h (1)

• 7-20: Addition of new declarations and methods related to proximity checks and marking foundations in DisplayClass is approved. Enhances building placement and interaction mechanics.

StaticInits.cpp (1)

• 119-127: Addition of HouseClass::FindSuperWeapon(SuperWeaponTypeClass* const type) method and bug fix in IsIonCannonEligibleTarget method in StaticInits.cpp is approved. Enhances super weapon handling and target eligibility checks.

YRMathVector.h (3)

• 19-24: Addition of new assignment operators for type conversions in Vector2D and Vector3D classes is approved. Enhances usability and functionality.
• 81-85: Addition of comparison operators for map keys in Vector2D and Vector3D classes is approved. Allows use as map keys.
• 125-129: Addition of an IsEmpty method to Vector2D and Vector3D classes is approved. Provides a straightforward way to check for empty vectors.

CellClass.h (2)

• 27-49: The TileType enum introduces hardcoded values for tile types. Ensure these values match expected game engine or documentation values, as hardcoded values can lead to maintenance issues if the underlying assumptions change.
• 221-227: The overloaded IsClearToMove method introduces default parameter values and calls the other overloaded version internally. Verify that the default value for level (-1) and the logic to determine isBridge using ContainsBridge() align with the game's movement and terrain rules.

TechnoClass.h (7)

• 26-26: The addition of class EBolt suggests new functionality related to electric attacks or effects. Ensure that its implementation is fully integrated with the rest of the TechnoClass methods and that it adheres to the game's mechanics for electric-based abilities or attacks.
• 191-197: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [194-218]

The method signatures for TurretFacing and GetRealFacing have been changed to use FacingClass* instead of DirStruct*. Confirm that all calls to these methods throughout the codebase have been updated to reflect this change, and verify that FacingClass provides the necessary functionality that DirStruct previously offered.

• 354-360: The method Fire_IgnoreType suggests a specific behavior for firing mechanics, potentially overriding default type checks. Ensure this behavior is documented and justified within the game's logic, especially regarding how it interacts with different target types and weapon systems.
• 370-374: The CreateLaser and Electric_Zap methods introduce new attack or effect types. Verify these methods are correctly implemented according to the game's specifications for laser and electric attacks, including proper handling of target types, damage calculations, and visual effects.
• 376-378: The DrawALinkTo method adds functionality for drawing visual links between points. Ensure this method is used consistently and appropriately within the game's visual effect system, and that it does not introduce performance issues when rendering multiple links in a scene.
• 632-633: The addition of the ROFTimer property and modification of the ROF property suggest changes to the rate of fire mechanics. Confirm that these changes are consistent with the intended gameplay balance and that the ROFTimer is correctly utilized in weapon firing logic.
• 503-511: The non-virtual methods TurretFacing and GetRealFacing provide convenience wrappers for their virtual counterparts. Ensure that these methods are used in contexts where the facing direction is required without modifying the underlying object, and that they correctly handle all possible states of turret and body facing.

HouseClass.h (2)

• 14-14: Addition of #include <SuperWeaponTypeClass.h> is appropriate for the new method signature that uses SuperWeaponTypeClass*. Ensure this new dependency is justified and used elsewhere in the file if possible to avoid unnecessary includes.
• 508-509: Modification of FindSuperWeapon method to take a SuperWeaponTypeClass* instead of SuperWeaponType improves type safety and clarity. Verify that all calls to this method have been updated accordingly across the codebase.

• BuildingClass.h (1 hunks)

BuildingClass.h (1)

• 258-259: Changing BState and QueueBState from int to BStateType improves type safety and clarity. Ensure all usages of these variables are updated to handle the new enum type correctly.

• ObjectClass.h (3 hunks)

ObjectClass.h (3)

• 11-11: The addition of #include <RulesClass.h> is appropriate for the new functionality introduced in this file, specifically for accessing RulesClass::Instance->C4Warhead in the overloaded TakeDamage method. This change ensures that the file has access to necessary game rules and configurations.
• 271-274: The first TakeDamage method added to ObjectClass includes parameters for specifying a WarheadTypeClass. This method correctly forwards these parameters to ReceiveDamage and handles the crewed and ignoreDefenses flags as per the previous review comments. Ensure that the logic for handling these flags is thoroughly tested, especially the inversion of the crewed flag to !crewed for the PreventPassengerEscape parameter in ReceiveDamage, as this could have nuanced effects on game mechanics.
• 276-279: The second TakeDamage method simplifies damage application by using a default warhead type from RulesClass. This method correctly forwards parameters to the first TakeDamage method, ensuring consistency in how damage is applied. Confirm that the default warhead type (C4Warhead) is appropriate for all use cases where this method might be called. This approach simplifies the method's usage for common damage scenarios but requires careful consideration of the default warhead's impact across different object types.

• FootClass.h (2 hunks)
• TechnoClass.h (8 hunks)

FootClass.h (2)

• 154-154: The introduction of the PlayingMovingSound property is a good enhancement for managing the state of moving sounds. Ensure that this property is properly updated in all relevant methods where the movement state of the unit changes. This might include starting movement, stopping movement, or any other state changes that could affect whether the unit should be playing a moving sound.
• 155-155: The addition of the MovingSoundDelay property is a thoughtful improvement for controlling the timing of moving sounds. It's crucial to ensure that this delay is utilized effectively in the logic that handles sound playing to avoid sound spamming or delays that are too long, which could lead to a lack of audio feedback for the player. Consider adding validation or constraints to ensure the delay value is within a reasonable range.

TechnoClass.h (10)

• 26-26: The addition of the EBolt class forward declaration is appropriate and aligns with the introduction of new electric attack functionalities like Electric_Zap.
• 194-194: Changing the method signature from DirStruct* to FacingClass* for TurretFacing likely enhances the handling of facing directions, aligning with the overall improvements in direction and facing handling mentioned in the summary.
• 218-218: The method signature change from DirStruct* to FacingClass* for GetRealFacing is consistent with other updates in the file, likely offering improved direction handling capabilities.
• 370-370: Changing the parameter type from ObjectClass* to AbstractClass* in CreateLaser method increases the flexibility in what can be targeted, aligning with the objective of enhancing functionality.
• 354-356: The addition of the InRange method enhances combat dynamics by allowing checks for whether a target is within range of a weapon, aligning with the system's objectives to refine combat and interaction capabilities.
• 358-360: The Fire_IgnoreType method introduces a significant enhancement in combat flexibility by allowing units to fire weapons regardless of the unit type, contributing to more strategic gameplay options.
• 373-375: The addition of the Electric_Zap method diversifies combat strategies by introducing electric-based attacks, aligning with the system's objectives to refine and expand combat capabilities.
• 376-378: The DrawALinkTo method contributes to visual enhancements by potentially allowing the drawing of visual effects or connections between two points, improving game clarity and immersion.
• 632-632: Renaming DiskLaserTimer to ROFTimer improves clarity and maintainability by indicating a broader use case for the variable, likely applicable to various weapons' rate of fire.
• 706-706: Renaming unknown_bool_432 to WasSelected significantly improves code readability and maintainability by clearly indicating the variable's purpose, likely related to UI or selection mechanics.

• Surface.h (7 hunks)

Surface.h (9)

• 15-15: The addition of the Pattern constant to the Surface class is a good practice for defining reusable patterns. However, ensure that its usage is properly documented, especially since it's a public member. Consider adding comments to explain its purpose and how it should be used in drawing operations.
• 113-114: The ClipLine method uses the JMP_STD macro for its implementation. Ensure that the macro correctly handles the logic for clipping lines within the specified bounds. It's also important to verify that the method's parameters (point1, point2, and Bounds) are correctly used and that the method is tested thoroughly for edge cases.
• 119-119: The modification in the initialization of ret in the GetRect method to { 0, 0, 0, 0 } is a clear way to initialize structures. Ensure that this change does not affect any existing functionality where GetRect is used, especially if previous default values were different or if uninitialized values were relied upon.
• 124-127: The DrawDashedLine method correctly utilizes the Pattern constant. Ensure that the method is thoroughly tested, particularly for the handling of the nOffset parameter, to avoid potential off-by-one errors or incorrect pattern rendering.
• 152-154: The addition of the VoxelSurface constant and the constructor for BSurface are well-implemented. Ensure that the Buffer initialization in the constructor takes into account the correct calculation for the buffer size based on Width, Height, and BytesPerPixel. Also, verify that the virtual table address (0x7E2070) is correctly set for BSurface instances.
• 216-218: The DrawLineBlit method in the DSurface class is a good addition for drawing lines with blitting. Ensure that the parameters (pRect, pStart, pEnd, pStartColor, mult, start_z, end_z) are correctly used within the method and that the method is tested for various scenarios, including edge cases.
• 232-244: The overloaded DrawSHP method introduces new default parameter values. Confirm that these defaults (Flags = (BlitterFlags)0x600, Brightness = 1000, TintColor = 0) are appropriate and do not inadvertently change the behavior of existing code that relies on this method. It's crucial to ensure compatibility with all calls to DrawSHP.
• 246-251: The second overloaded DrawSHP method simplifies drawing by automatically determining the bounds. Ensure that the automatic bounds calculation (this->GetRect()) works correctly in all scenarios and does not introduce unexpected behavior, especially in edge cases where specific bounds are expected.
• 229-257: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [254-266]

The DrawText methods provide flexibility in drawing text with different parameters. Ensure that the default values for BackColor and Flag in the overloaded methods are sensible and that all variations of DrawText are tested for correct text rendering, especially in cases with different background colors and shadow types.

• TechnoClass.h (9 hunks)

• TechnoClass.h

• CellClass.h (3 hunks)

CellClass.h (2)

• 27-49: The addition of the TileType enum class introduces a structured way to represent different types of tiles within the game. This is a positive change as it enhances code readability and maintainability by replacing magic numbers or strings with a strongly-typed enumeration. However, it's important to ensure that the values assigned to each enum member (e.g., Tunnel = 0x484AB0) are correct and meaningful within the context of the game's logic. If these values are intended to be memory addresses or function pointers (which seems unusual), this should be clearly documented to avoid confusion.
• 328-351: The GetTileType method implementation is straightforward and aligns with the newly introduced TileType enum, providing a way to determine the tile type based on specific conditions. This method is a good example of encapsulating game logic related to tile types within the CellClass. However, as previously mentioned in the comments from the outdated commits, consider if there's a more efficient way to map or query these tile types, especially if this method is called frequently in performance-critical paths. If performance is not a concern or if the current approach is the most suitable given the game's architecture, then this implementation is acceptable.

• AircraftTrackerClass.h (1 hunks)

AircraftTrackerClass.h (4)

• 21-21: The use of constant_ptr for Instance is an interesting choice, ensuring type safety and const correctness. However, it's crucial to ensure that the memory address 0x887888u is correctly mapped and does not lead to any potential issues such as memory leaks or access violations.
• 24-24: The explicit declaration of a destructor with RX is noted. Ensure that the destructor properly cleans up any dynamically allocated resources to prevent memory leaks. This is particularly important in a class that manages a collection of pointers.
• 26-36: The methods Add_Entry, Remove_Entry, Update_Entry, and Search_Entry use the JMP_THIS macro for their implementations. This approach is specific to hooking or patching compiled binaries and is not common in standard C++ development. Ensure that this technique is consistent with the project's coding standards and that it does not introduce any security or stability issues.
• 47-48: The properties Technos and Current are declared using DECLARE_PROPERTY. This macro likely simplifies the declaration of getters and setters for these properties. Ensure that the macro correctly handles memory management and thread safety, especially since DynamicVectorClass<TechnoClass*> involves pointers to objects that may be modified or deleted elsewhere in the code.

• AircraftClass.h (1 hunks)

AircraftClass.h (2)

• 64-64: Renamed unknown_bool_6C8 to LoseAmmo for clarity.

This renaming improves code readability by providing a meaningful name for the variable. Ensure that all references to this variable in the codebase have been updated accordingly.

• 70-72: Added IsLocked, ParadropsLeft, and IsCarrayall boolean flags.

These additions seem to enhance the functionality and state management of the AircraftClass. It's important to ensure that these new flags are properly initialized in the class constructor and handled correctly throughout the codebase.

• InfantryClass.h (1 hunks)

• ObjectTypeClass.h (1 hunks)

• CellClass.h (5 hunks)
• JumpjetLocomotionClass.h (1 hunks)
• MissionClass.h (1 hunks)

• CellClass.h

JumpjetLocomotionClass.h (1)

• 62-63: Consider adding documentation for the GetZBalloonHover method to explain its purpose and how it integrates with the rest of the class's functionality. This will improve maintainability and understandability of the code.

MissionClass.h (1)

• 92-93: Consider adding documentation for the Mission_Move_Carryall function to explain its specific use case for AircraftClass. Additionally, implementing type safety or checks to ensure it's only used with AircraftClass could prevent potential misuse and improve code safety.

• TacticalClass.h (1 hunks)

TacticalClass.h (1)

• 36-40: The addition of the CoordsToClient method is a good enhancement for simplifying the usage of converting coordinates to client space. It encapsulates the buffer handling internally, making the API cleaner for callers.

However, consider adding a brief comment above the method to explain its purpose and usage, especially since it overloads an existing method. This will improve code readability and maintainability.

• JumpjetLocomotionClass.h (2 hunks)

• JumpjetLocomotionClass.h

• JumpjetLocomotionClass.h (1 hunks)

• JumpjetLocomotionClass.h

• ShipLocomotionClass.h (1 hunks)

ShipLocomotionClass.h (1)

31-32: Renaming Ramp1 and Ramp2 to PreviousRamp and CurrentRamp improves the semantic clarity of these variables. This change likely enhances the readability and maintainability of the code by making the purpose of these variables more explicit. Ensure that all references to these variables throughout the codebase have been updated accordingly to reflect the new names.

Verification successful

---

The renaming of Ramp1 and Ramp2 to PreviousRamp and CurrentRamp has been successfully verified in the ShipLocomotionClass.h file, and no references to the old variable names were found. Additionally, it was discovered that similar changes were applied to the DriveLocomotionClass.h file, indicating a broader scope of the renaming effort than initially reviewed. This broader application of the changes should be noted, but it does not affect the approval of the changes made to ShipLocomotionClass.h. All references to these variables throughout the codebase appear to have been updated accordingly to reflect the new names.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Search to find files that might reference the old ramp variables. Expecting no results.
rg --type cpp $'Ramp1|Ramp2'
# Search new variable names to validate usage. Expecting list of locations where the new names are used.
rg --type cpp $'PreviousRamp|CurrentRamp'

Length of output: 244

Reviewing files that changed from the base of the PR and between 70ffa73 and 671847d.

• HouseClass.h

HouseClass.h (2)

508-509: Implementation verified and properly handles null pointers.

The new overload at StaticInits.cpp:119-127 correctly implements the declaration. When a null pointer is passed, the loop safely returns nullptr without finding a match, which is the appropriate behavior.

---

1017-1017: No action required—the type change from DWORD to int is correct and consistent with the codebase.

The power system throughout YRpp (PowerOutput, PowerDrain, and related fields in HouseClass, BuildingTypeClass, and PowerClass) consistently uses int (signed 32-bit), not DWORD. PowerSurplus as int aligns with the existing design and supports the logical use case of representing power surplus/deficit (which can be negative). All power comparisons and calculations already assume signed integer semantics.