client/src/ui/components/military/UserBattles.tsx (2)

1-3: Consider using absolute imports consistently.

While the first import uses an absolute path (@/), the second one uses a relative path. Consider using absolute imports consistently for better maintainability.

-import { BattleListItem } from "../battles/BattleListItem";
+import { BattleListItem } from "@/ui/components/battles/BattleListItem";

---

8-8: Make the width responsive.

The hardcoded width might not work well on different screen sizes. Consider using responsive width classes.

-    <div className="w-[31rem] py-2 pl-2">
+    <div className="w-full md:w-[31rem] py-2 pl-2">

client/src/ui/elements/Checkbox.tsx (1)

3-7: Consider using a more semantic name for the onClick prop.

While the implementation is correct, consider renaming onClick to something more specific like onToggle or onStateChange to better reflect its purpose in a checkbox context.

 type CheckboxProps = {
   enabled: boolean;
-  onClick?: () => void;
+  onToggle?: () => void;
   text?: string;
 };

client/src/ui/modules/military/Military.tsx (2)

17-27: Consider memoizing the tabs configuration.

The tabs array is recreated on every render. Consider using useMemo to optimize performance.

+const tabs = useMemo(() => [
-const tabs = [
   {
     label: "Army",
     component: isMapView ? (
       <EntitiesArmyTable />
     ) : (
       selectedStructure && <EntityArmyList structure={selectedStructure} />
     ),
   },
   { label: "Battles", component: <UserBattles /> },
-];
+], [isMapView, selectedStructure]);

---

31-49: Enhance accessibility with explicit ARIA labels.

While the tabs implementation is solid, consider adding explicit ARIA labels for better accessibility.

 <Tabs
   selectedIndex={selectedTab}
   onChange={(index: number) => {
     setSelectedTab(index);
   }}
-  className="h-full"
+  className="h-full"
+  aria-label="Military Information"
 >

client/src/ui/modules/entity-details/Entities.tsx (3)

11-19: Add JSDoc documentation for the component props

Consider adding JSDoc documentation to describe the purpose of each prop, especially the new battles prop, to improve code maintainability.

+/**
+ * Entities component displays various entity details including structures, battles, and armies
+ * @param position - The position coordinates on the map
+ * @param ownArmy - The player's army information if present
+ * @param battles - List of battles occurring at the given position
+ */
 export const Entities = ({
   position,
   ownArmy,
   battles,
 }: {

---

20-22: Consider persisting user preferences for section visibility

The visibility states are reset to true on every component mount. Consider storing these preferences in localStorage or user settings to maintain consistency across sessions.

+const STORAGE_KEY = 'entityDetails.visibility';
+
+const getStoredVisibility = () => {
+  try {
+    return JSON.parse(localStorage.getItem(STORAGE_KEY) || '{}');
+  } catch {
+    return {};
+  }
+};
+
 const [showStructure, setShowStructure] = useState(true);
 const [showBattles, setShowBattles] = useState(true);
 const [showArmies, setShowArmies] = useState(true);
+
+useEffect(() => {
+  const stored = getStoredVisibility();
+  if (stored.showStructure !== undefined) setShowStructure(stored.showStructure);
+  if (stored.showBattles !== undefined) setShowBattles(stored.showBattles);
+  if (stored.showArmies !== undefined) setShowArmies(stored.showArmies);
+}, []);

---

31-36: Consider improving responsive design for the checkbox grid

While the grid layout works well, using grid-cols-3 might cause issues on smaller screens. Consider making it responsive.

-<div className="w-full grid grid-cols-3">
+<div className="w-full grid grid-cols-1 sm:grid-cols-2 md:grid-cols-3 gap-2">

scripts/indexer.sh (1)

Line range hint 1-91: Consider enhancing script reliability and observability.

The script handles critical deployment and indexing setup, but could benefit from some architectural improvements:

1. Add error checking after critical operations (contract deployment, file operations)
2. Validate generated contract addresses before updating configuration
3. Add logging to track important state changes
4. Consider using environment variables for configurable values

Example improvements:

 #!/bin/bash
+
+# Exit on error
+set -e
+
+# Logging function
+log_info() {
+    echo "[INFO] $(date '+%Y-%m-%d %H:%M:%S') - $1"
+}
+
+# Error handling function
+handle_error() {
+    echo "[ERROR] $(date '+%Y-%m-%d %H:%M:%S') - $1" >&2
+    exit 1
+}
+
+# Validate contract address
+validate_address() {
+    local addr=$1
+    if [[ ! $addr =~ ^0x[a-fA-F0-9]{64}$ ]]; then
+        handle_error "Invalid contract address format: $addr"
+    fi
+}

Consider extracting configurable values to environment variables:

-torii --world 0x05013b17c43a2b664ec2a38aa45f6d891db1188622ec7cf320411321c3248fb5 \
+torii --world "${WORLD_ADDRESS}" \

client/src/hooks/helpers/battles/useBattles.tsx (1)

91-107: Consider performance optimizations

The current implementation involves multiple array transformations and queries which could impact performance with large datasets.

Consider these optimizations:

 export const useUserBattles = () => {
   const {
     setup: {
       components: { Army, Battle, EntityOwner, Position, Structure },
     },
   } = useDojo();

   const { playerRealms } = useEntities();
   const realms = playerRealms();

-  const battleEntityIds = realms
-    .map((realm) => {
-      const userArmiesInBattleEntityIds = runQuery([
-        Has(Army),
-        NotValue(Army, { battle_id: 0 }),
-        HasValue(EntityOwner, { entity_owner_id: realm.entity_id }),
-      ]);
-      const battleEntityIds = Array.from(userArmiesInBattleEntityIds)
-        .map((armyEntityId) => {
-          const army = getComponentValue(Army, armyEntityId);
-          if (!army) return;
-          return getEntityIdFromKeys([BigInt(army.battle_id)]);
-        })
-        .filter((battleEntityId): battleEntityId is Entity => Boolean(battleEntityId));
-      return battleEntityIds;
-    })
-    .flatMap((battleEntityIds) => Array.from(battleEntityIds));
+  // Use Set to avoid duplicate battle IDs
+  const battleEntityIds = new Set<Entity>();
+  
+  for (const realm of realms) {
+    const userArmiesInBattle = runQuery([
+      Has(Army),
+      NotValue(Army, { battle_id: 0 }),
+      HasValue(EntityOwner, { entity_owner_id: realm.entity_id }),
+    ]);
+    
+    for (const armyEntityId of userArmiesInBattle) {
+      const army = getComponentValue(Army, armyEntityId);
+      if (army) {
+        battleEntityIds.add(getEntityIdFromKeys([BigInt(army.battle_id)]));
+      }
+    }
+  }
+  
+  return getExtraBattleInformation(Array.from(battleEntityIds), Battle, Position, Structure);

client/src/ui/modules/entity-details/EnemyArmies.tsx (2)

107-114: Simplify fragment nesting and improve heading semantics

The current implementation has unnecessary fragment nesting. Consider simplifying the structure and improving the heading's semantic meaning.

Here's a suggested improvement:

-        <>
-          <h5 className="pl-2 ">Enemy armies</h5>
-          <React.Fragment>
-            <div className="grid grid-cols-1 gap-2 p-2">
-              {armies.length > 0 && armies.map((army: ArmyInfo, index) => getArmyChip(army, index)).filter(Boolean)}
-            </div>
-          </React.Fragment>
-        </>
+        <section aria-label="Enemy armies">
+          <h2 className="pl-2 text-sm font-semibold">Enemy armies</h2>
+          <div className="grid grid-cols-1 gap-2 p-2">
+            {armies.length > 0 && armies.map((army: ArmyInfo, index) => getArmyChip(army, index)).filter(Boolean)}
+          </div>
+        </section>

---

111-111: Simplify the army length check condition

The current implementation has a redundant length check since the outer condition already ensures armies.length !== 0.

Consider simplifying:

-              {armies.length > 0 && armies.map((army: ArmyInfo, index) => getArmyChip(army, index)).filter(Boolean)}
+              {armies.map((army: ArmyInfo, index) => getArmyChip(army, index)).filter(Boolean)}

client/src/ui/modules/entity-details/CombatEntityDetails.tsx (1)

55-55: Add validation for battles data.

While passing battles data to the Entities component aligns with the PR objective to display battles in the military tab, consider adding validation to handle cases where battles data might be undefined or null.

- component: selectedHex && <Entities position={hexPosition} ownArmy={ownArmy} battles={battles} />,
+ component: selectedHex && <Entities position={hexPosition} ownArmy={ownArmy} battles={battles ?? []} />,

client/src/ui/components/battles/BattleListItem.tsx (2)

Line range hint 81-85: Add error handling for undefined battle state

While the simplified logic is clearer, consider adding error handling for cases where updatedBattle might be undefined in the click handlers.

 onClick={() =>
+  if (!updatedBattle) return;
   setBattleView({
     battleEntityId: updatedBattle!.entity_id,
     targetArmy: undefined,
     ownArmyEntityId: ownArmySelected!.entity_id,
   })
 }

---

94-94: Consider extracting battle content into a separate component

The nested JSX structure is becoming complex. Consider extracting the battle content into a separate component for better maintainability.

// Suggested new component
const BattleContent: React.FC<{
  battle: BattleInfo;
  updatedBattle: Battle;
  showCompass: boolean;
  position: Position;
}> = ({ battle, updatedBattle, showCompass, position }) => (
  <div className="flex w-full justify-between">
    {/* ... existing content ... */}
  </div>
);

Also, the hideTooltip prop is hardcoded to true for ViewOnMapIcon. Consider making this configurable if there are cases where the tooltip might be needed.

Also applies to: 99-100

contracts/src/systems/map/map_generation.cairo (1)

Line range hint 171-199: Consider refactoring for improved maintainability.

The troop generation logic could benefit from some refactoring:

1. Extract random troop count generation into a helper function to reduce code duplication
2. Consider splitting army creation and troop assignment into separate functions for better separation of concerns

Here's a suggested refactoring approach:

fn generate_random_troop_count(
    salt: u256,
    lower_bound: u64,
    upper_bound: u64,
) -> u64 {
    random::random(
        salt.low,
        upper_bound.into() - lower_bound.into()
    )
        .try_into()
        .unwrap()
        + lower_bound
}

fn generate_mercenary_troops(
    tx_hash: felt252,
    timestamp: u64,
    nonce: felt252,
    config: MercenariesConfig,
) -> Troops {
    let salt_one: u256 = tx_hash.into();
    let salt_two: u256 = timestamp.into();
    let salt_three: u256 = nonce.into();

    let mut troops = Troops {
        knight_count: generate_random_troop_count(
            salt_one,
            config.knights_lower_bound,
            config.knights_upper_bound
        ),
        paladin_count: generate_random_troop_count(
            salt_two,
            config.paladins_lower_bound,
            config.paladins_upper_bound
        ),
        crossbowman_count: generate_random_troop_count(
            salt_three,
            config.crossbowmen_lower_bound,
            config.crossbowmen_upper_bound
        )
    };
    troops.normalize_counts();
    troops
}

client/src/hooks/helpers/useEntities.tsx (1)

160-161: Consider optimizing the sorting implementation

The current implementation performs filtering and sorting on every render. Consider maintaining a sorted state of playerStructures to avoid the double iteration.

Here's a suggested optimization:

  const playerStructures = useMemo(() => {
    return filterPlayerStructures
      .map((id) => {
        // ... existing mapping logic ...
      })
      .filter((structure): structure is PlayerStructure => structure !== undefined)
      .sort((a, b) => {
        if (a.category === StructureType[StructureType.Realm]) return -1;
        if (b.category === StructureType[StructureType.Realm]) return 1;
-       return a.category.localeCompare(b.category);
+       // Sort by category first, then by name
+       const categoryCompare = a.category.localeCompare(b.category);
+       return categoryCompare !== 0 ? categoryCompare : a.name.localeCompare(b.name);
      });
  }, [filterPlayerStructures]);

  const getPlayerStructures = (filterFn?: (structure: PlayerStructure) => boolean) => {
    return useMemo(() => {
-     const structures = filterFn ? playerStructures.filter(filterFn) : playerStructures;
-     return structures.sort((a, b) => a.name.localeCompare(b.name));
+     return filterFn ? playerStructures.filter(filterFn) : playerStructures;
    }, [playerStructures, filterFn]);
  };

contracts/src/systems/combat/contracts/troop_systems.cairo (2)

Line range hint 333-411: Consider improving maintainability of military building calculations.

The military building count calculation could be extracted into a helper function for better maintainability and reusability. Additionally, the stamina initialization logic is complex and could benefit from being moved to a dedicated function.

Consider refactoring like this:

-                let total_military_building_count = stables_building_count
-                    + archery_range_building_count
-                    + barracks_building_count;
+                let total_military_building_count = calculate_total_military_buildings(
+                    stables_building_count,
+                    archery_range_building_count,
+                    barracks_building_count
+                );

And add this helper function:

fn calculate_total_military_buildings(
    stables: u128,
    archery: u128,
    barracks: u128
) -> u128 {
    stables + archery + barracks
}

---

Line range hint 438-461: LGTM! Base army creation is thorough and secure.

The implementation correctly validates ownership and initializes all required components. However, consider adding a comment explaining the significance of the default battle_id (0) and battle_side values for better maintainability.

Add a comment like this:

 world
     .write_model(
         @Army {
-            entity_id: army_id, troops: Default::default(), battle_id: 0, battle_side: Default::default()
+            entity_id: army_id,
+            troops: Default::default(),
+            battle_id: 0, // 0 indicates army is not in battle
+            battle_side: Default::default() // Default side until army joins a battle
         }
     );

contracts/manifest_dev.json (1)

Contract address format issue detected

Found one contract address that doesn't match the expected format:
"0x3a6bbb82f9e670c99647f3b0c4aaf1be82be712e1a393336b79b9dab44cc5"

While all class hashes are valid, this address appears to be truncated or malformed as it's shorter than the expected 62-64 hex characters after '0x'. This could cause issues with contract interactions.

🔗 Analysis chain

Line range hint 1246-4036: Contract definitions are well-structured!

The contracts follow best practices with:

• Clear separation of concerns (bank, battle, building systems, etc.)
• Consistent implementation of upgradeable pattern
• Standardized event handling
• Well-defined interfaces and systems

Verify the contract addresses are correctly configured:

---

The script results show no duplicate addresses or class hashes were found, which is good. However, let's verify the format and validity of the addresses and class hashes to ensure they follow the expected pattern.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify contract addresses are valid and match class hashes

# Check for any duplicate addresses
echo "Checking for duplicate addresses..."
grep -A 1 '"address":' contracts/manifest_dev.json | grep "0x" | sort | uniq -d

# Check for any duplicate class hashes
echo "Checking for duplicate class hashes..."
grep -A 1 '"class_hash":' contracts/manifest_dev.json | grep "0x" | sort | uniq -d

Length of output: 330

---

Script:

#!/bin/bash
# Verify address and class hash format

# Check address format (should be 0x followed by 62-64 hex chars)
echo "Checking address format..."
grep '"address":' contracts/manifest_dev.json | grep -v '0x[0-9a-f]\{62,64\}"' || echo "All addresses valid"

# Check class hash format (should be 0x followed by 62-64 hex chars)
echo "Checking class hash format..."
grep '"class_hash":' contracts/manifest_dev.json | grep -v '0x[0-9a-f]\{62,64\}"' || echo "All class hashes valid"

# Count total number of contracts
echo "Total contracts:"
grep '"address":' contracts/manifest_dev.json | wc -l

Length of output: 537

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Verify the UserBattles component implementation
ast-grep --pattern 'export const UserBattles = $_' 

#!/bin/bash
# Check the useUserBattles hook implementation
ast-grep --pattern 'export const useUserBattles = $_'

# Check the BattleListItem component
ast-grep --pattern 'export const BattleListItem = $_'

#!/bin/bash
# Description: Verify proper battle integration and usage

# Check for proper battle prop passing in parent components
rg -l "Entities.*battles={" --type tsx

# Check for proper battle type usage
ast-grep --pattern 'type $_ = { battles: BattleInfo[] }'

#!/bin/bash
# Let's break down the verification into steps

# 1. Check how battles are passed to Entities component
rg "battles.*Entities" --type tsx -B 2 -A 2

# 2. Check the Battles component implementation
rg "export.*Battles" --type tsx -B 2 -A 2

# 3. Look for BattleInfo type definition
rg "type.*BattleInfo" --type ts --type tsx -B 1 -A 3

# 4. Check for battle-related props and interfaces
rg "interface.*\{.*battles" --type ts --type tsx -B 1 -A 3

#!/bin/bash
# Let's try without file type restrictions since tsx isn't recognized

# 1. Check how battles are passed to Entities component
rg "battles.*Entities" -B 2 -A 2

# 2. Check the Battles component implementation and its props
rg "export.*Battles" -B 2 -A 2

# 3. Look for BattleInfo type/interface
rg "BattleInfo" -B 2 -A 2

# 4. Look for files containing Battles component
fd "Battles.tsx"

#!/bin/bash
# Search for military tab integration
rg -l "military.*tab|tab.*military" --type tsx

# Check for battle-related components in the military context
ast-grep --pattern 'const $military = $_ => {
  $$$
  return (
    $$$
    <$EnemyArmies $$$/>
    $$$
  )
}'

#!/bin/bash
# Search for military tab integration with correct file extension
rg -l "military.*tab|tab.*military" --type ts --type tsx

# Find files containing EnemyArmies component usage
rg -l "EnemyArmies"

# Look for military-related components and tabs
ast-grep --pattern 'import { $_ as EnemyArmies } from "$_"'

# Check for tab definitions that might include military
rg "military" -B 2 -A 2

#!/bin/bash
# Search for battle selection logic
rg -A 10 'selectBattle|battle.*selection'

# Search for hyperstructure attack handling
ast-grep --pattern 'function $_($$$ hyperstructure $$$) {
  $$$
}'

#!/bin/bash
# Search for battle-related components and logic
rg -A 10 "battles?.find|battles?.filter"

# Search for battle selection in Entities component
fd -e tsx -e ts "Entities.tsx" --exec cat

# Look for battle handling in combat actions
rg -A 10 "handleAttack|attackEntity"

#!/bin/bash
# Search for battle-related components
fd -e tsx -e ts "Battles.tsx" --exec cat

# Search for battle selection in combat actions
fd -e tsx -e ts "Combat" --exec rg -A 10 "battle|attack"

#!/bin/bash
# Check if BattleListItem is properly integrated in the military tab
rg -l "BattleListItem.*showCompass={true}" src/

#!/bin/bash
# Search for BattleListItem usage in the codebase
rg -l "BattleListItem" src/

# Search for military tab related components
rg -l "Military.*Tab" src/

# Search for showCompass prop usage
rg "showCompass" src/

#!/bin/bash
# Search for BattleListItem usage in the codebase
rg -l "BattleListItem" client/src/

# Search for military tab related components
rg -l "Military.*Tab" client/src/

# Search for showCompass prop usage
rg "showCompass" client/src/

#!/bin/bash
# Check the content of UserBattles.tsx to verify military tab integration
cat client/src/ui/components/military/UserBattles.tsx

# Check Battles.tsx to understand the component usage
cat client/src/ui/modules/entity-details/Battles.tsx

#!/bin/bash
# Description: Search for any remaining calls to create_defensive_army that might still use the old signature with owner_address

# Search for create_defensive_army calls
ast-grep --pattern 'create_defensive_army($$$)'

# Also check for any TODO or FIXME comments related to army creation
rg -i "todo|fixme|hack|xxx|bug.*army.*creat" 

#!/bin/bash
# Search for create_defensive_army function implementation and calls
ast-grep --pattern 'create_defensive_army($$$)'

# Also search for any references to defensive army creation
rg -A 3 "create_defensive_army"

#!/bin/bash
# Search for any remaining calls using the old signature with owner_address
ast-grep --pattern 'create_attacking_army($_, $_, $_)' 
ast-grep --pattern 'create_defensive_army($_, $_, $_)'

#!/bin/bash
# Let's try a different approach using ripgrep to find all occurrences of these method calls
rg "create_attacking_army|create_defensive_army" -A 2 -B 2

client/src/ui/components/structures/worldmap/StructureCard.tsx (4)

Line range hint 126-142: Consider using dynamic height calculation for better responsiveness

The fixed max-height of 42vh might not provide optimal user experience across different screen sizes and resolutions.

Consider using a more responsive approach:

-<div className="flex flex-col  bg-gold/20 p-3 max-h-[42vh] overflow-y-auto">
+<div className="flex flex-col bg-gold/20 p-3 max-h-[calc(100vh-200px)] min-h-[300px] overflow-y-auto">

---

Line range hint 264-297: Add error handling for army creation and deletion operations

The army creation and deletion operations lack proper error handling, which could lead to inconsistent state.

Consider adding try-catch blocks and user feedback:

 const createProtector = async () => {
   setLoading(true);
+  try {
     await create_army({
       signer: account,
       is_defensive_army: true,
       army_owner_id: structureEntityId!,
     });
+  } catch (error) {
+    console.error('Failed to create army:', error);
+    // Add user feedback here
+  } finally {
     setLoading(false);
+  }
 };

---

Line range hint 299-332: Protect against race conditions in mergeTroops function

The mergeTroops function modifies state and performs multiple async operations without proper synchronization.

Consider implementing optimistic updates and proper error handling:

 const mergeTroops = async () => {
   setLoading(true);
+  const previousTroopsGiven = { ...troopsGiven };
+  try {
     const fromArmy = transferDirection === "to" ? getArmy(giverArmyEntityId) : takerArmy || getArmy(protector!.army_id);
     const toArmy = transferDirection === "to" ? takerArmy || getArmy(protector!.army_id) : getArmy(giverArmyEntityId);
     
     if (!fromArmy || !toArmy) {
+      throw new Error('Invalid army configuration');
     }
     
     // ... rest of the code ...
     
     if (fromArmy && !Boolean(fromArmy?.protectee) &&
         getTotalTroops(fromArmy.troops) - getTotalTroops(transferedTroops) === 0) {
+      try {
         world.deleteEntity(getEntityIdFromKeys([BigInt(fromArmy?.entity_id || 0)]));
+      } catch (error) {
+        console.error('Failed to delete empty army:', error);
+      }
     }
+  } catch (error) {
+    console.error('Merge operation failed:', error);
+    setTroopsGiven(previousTroopsGiven); // Rollback on failure
+  } finally {
     setLoading(false);
+  }
 };

---

Line range hint 333-401: Enhance accessibility for interactive elements

The UI components lack proper accessibility attributes which could make it difficult for users with assistive technologies.

Add appropriate ARIA labels and improve color contrast:

-<Button
+<Button
+  aria-label={`Transfer troops ${transferDirection}`}
   onClick={mergeTroops}
   isLoading={loading}
   variant="primary"
   className="mt-3"
   disabled={Object.values(troopsGiven).every((amount) => amount === 0n) || (!protector && !takerArmy)}
 >
   Reinforce
 </Button>

-<div className={`text-lg font-bold col-span-3 text-center ${
+<div
+  role="status"
+  aria-label={`Troop transfer amount: ${troopsGiven[Number(resourceId)]}`}
+  className={`text-lg font-bold col-span-3 text-center ${
     troopsGiven[Number(resourceId)] !== 0n ? `text-green` : ""
   }`}
 >

contracts/manifest_dev.json (1)

Line range hint 1-8875: Consider adding documentation for contract interactions

While the manifest defines all the contracts, models and events, it would be helpful to add documentation on:

• Expected interaction flows between contracts
• Event emission patterns
• Model relationships and constraints

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Check for battle-related component dependencies
echo "Checking battle system integration..."

# Look for battle system imports and usage
rg -l "battle|Battle" --type ts --type tsx

# Check for potential circular dependencies
ast-grep --pattern 'import { $_ } from "$_/battle"'

# Verify proper event handling
ast-grep --pattern 'on$_(battle|Battle)$_'

#!/bin/bash
# Check for battle-related component dependencies with correct file type
echo "Checking battle system integration..."

# Look for battle system imports and usage
rg -l "battle|Battle" --type typescript --type tsx

# Check battle-related functions in StructureCard
rg -A 5 "battle|Battle" client/src/ui/components/structures/worldmap/StructureCard.tsx

# Check getTotalTroops implementation
rg -A 5 "getTotalTroops" 

#!/bin/bash
# Description: Verify battle contract references
# Expected: Updated contract addresses should be referenced consistently

# Search for contract address references
rg -l "0x[a-f0-9]{40,}" --glob '!manifest*.json' --glob '!*.md'

#!/bin/bash
# Description: Verify world contract address and class hash references
# Expected: No other files should reference the old values

# Search for old address/hash references
rg -l "0x[a-f0-9]{40,}" --glob '!manifest*.json' --glob '!*.md'

#!/bin/bash
# Let's check the actual content of files that might reference contract addresses
# to see if they contain the specific old world contract address/hash

# Check deploy scripts and configuration files first
echo "=== Checking deploy.sh ==="
rg "0x5013b17c43a2b664ec2a38aa45f6d891db1188622ec7cf320411321c3248fb5" scripts/deploy.sh -A 2 -B 2 || true
echo "=== Checking dojoConfig files ==="
rg "0x5013b17c43a2b664ec2a38aa45f6d891db1188622ec7cf320411321c3248fb5" client/dojoConfig.ts landing/dojoConfig.ts -A 2 -B 2 || true
echo "=== Checking dojo configuration files ==="
rg "0x5013b17c43a2b664ec2a38aa45f6d891db1188622ec7cf320411321c3248fb5" contracts/dojo_dev.toml contracts/torii.toml -A 2 -B 2 || true

echo "\n=== Checking for class hash ==="
rg "0x79d9ce84b97bcc2a631996c3100d57966fc2f5b061fb1ec4dfd0040976bcac6" --glob '!manifest*.json' -A 2 -B 2 || true

#!/bin/bash
# Let's check if these values appear in any configuration or environment files
# but this time let's look for partial matches to catch potential variations

echo "=== Checking for partial world contract address matches ==="
rg "0x5013b17" --glob '!manifest*.json' -A 2 -B 2 || true

echo "=== Checking SDK constants ==="
cat sdk/packages/eternum/src/constants/global.ts || true

echo "=== Checking environment variables ==="
cat contracts/scripts/env_variables.sh || true

echo "=== Checking dojo configuration ==="
cat contracts/dojo_dev.toml || true

client/src/hooks/helpers/battles/useBattles.tsx (1)

101-104: Add type safety for army.battle_id

The current implementation assumes battle_id exists and is non-zero, but there's no type checking.

Add type guards:

-const army = getComponentValue(Army, armyEntityId);
-if (!army) return;
-return getEntityIdFromKeys([BigInt(army.battle_id)]);
+const army = getComponentValue(Army, armyEntityId);
+if (!army?.battle_id || typeof army.battle_id !== 'number') return;
+return getEntityIdFromKeys([BigInt(army.battle_id)]);

Configuration used: CodeRabbit UI
Review profile: CHILL

contracts/src/systems/combat/contracts/troop_systems.cairo (1)

Line range hint 430-455: Consider using a more flexible resource locking mechanism

Instead of using Bounded::MAX for release_at, consider implementing a mechanism that allows for future modifications if needed. This could be important for contract upgrades or policy changes.

-    @ResourceTransferLock {
-        entity_id: army_id, start_at: starknet::get_block_timestamp(), release_at: Bounded::MAX
-    }
+    @ResourceTransferLock {
+        entity_id: army_id,
+        start_at: starknet::get_block_timestamp(),
+        release_at: starknet::get_block_timestamp() + DEFENSIVE_ARMY_LOCK_DURATION
+    }

Configuration used: CodeRabbit UI
Review profile: CHILL

let total_allowed_armies = troop_config.army_free_per_structure.into()
    + (troop_config.army_extra_per_building.into() * total_military_building_count);