[Shalinihr1402]

Hello,I pushed another commit to update this based on the issue discussion.

Instead of doing string checks for "Hab" or "Hub", I added a new shape="circular" attribute straight into the XML config for these buildings.

Now BuildingConfig.java reads the shape and calculates the exact circular floor area using pi * r^2. LifeSupport.java just pulls that accurate area directly. This completely fixes the life support overestimations for circular buildings and removes the hardcoded string checks.

Title: Refactor building area calculation to use XML shape attribute

Description:

This PR resolves the issue regarding incorrect floor area calculations for circular buildings (Habs/Hubs) and removes the fragile string-matching logic in the Java code.

What was changed:

XML Configuration (buildings.xml):

Added a new shape attribute (CDATA #IMPLIED) to the building DTD.
Tagged all applicable circular buildings (Lander Hab, Storage Hab, Research Hab, Residential Hab, Medical Hab, Machinery Hab) with shape="circular".
Configuration Parsing (BuildingConfig.java & BuildingSpec.java):

BuildingConfig now parses the shape attribute.
The area calculation in parseBuilding() is now mathematically accurate: if shape="circular", it uses Math.PI * (length / 2.0) * (length / 2.0). Otherwise, it falls back to the standard rectangular width * length.
Plumbed the shape property through BuildingSpec.java so it can be queried downstream.
Life Support Fix (LifeSupport.java):

Removed the hardcoded (and incorrect for circular buildings) floorArea = length * width calculation.
It now cleanly pulls the accurate area via floorArea = building.getFloorArea().
Business Logic Cleanup (Building.java):

Refactored the isAHabOrHub() method. Instead of relying on fragile string matching (name.toLowerCase().contains("hab")), it now explicitly checks if the building's spec shape is "circular". This is much safer and purely data-driven.

[bevans2000]

Right I have found the PR. The changes look good and exactly what we want.
The problem is your forked repo is from my personal fork not the official marssim repo. This means your base commit is very old and merging it into the official mars repo will have conflicts.
I suggest you take another fork from the official repo and reapply your changes, then your PR will be going direct into the correct repo.

[Shalinihr1402]

yeah,sure

[Shalinihr1402]

@bevans2000 I noticed the Java CI tests failed on my earlier commit, so I pushed a quick fix!

The automated unit tests were throwing a NullPointerException because the global BuildingManager isn't fully initialized during the CI test suite. I updated Building.java to safely capture the shape and floorArea during initialization instead of querying the global manager for the BuildingSpec. This makes it completely test-safe.

The CI should pass green now! Let me know if everything looks good.

[bevans2000]

Yes that constructor pattern is used in unit tests. Look green now. I just added some review comments