Skip to content

Added support for diesel engine - #1432

Open
m-tra wants to merge 1 commit into
JSBSim-Team:masterfrom
m-tra:master
Open

Added support for diesel engine#1432
m-tra wants to merge 1 commit into
JSBSim-Team:masterfrom
m-tra:master

Conversation

@m-tra

@m-tra m-tra commented Apr 14, 2026

Copy link
Copy Markdown

For a University project implying the modelization of a light aircraft, powered by a naturally aspirated diesel engine, I felt the need to add support and calculation to specific diesel parameters. The main functionalities are derived from the FGPiston class, but with diesel-only calculations. The support for turbo aircraft is very basic, as this was not the focus of our project.

@bcoconni

Copy link
Copy Markdown
Member

Thanks for your contribution.

After a quick review, it seems that the files FGPistionDiesel.* have a lot of commonality with FGPiston.*. I am planning to perform a diff between the files to understand what exactly are the differences. If my first impression is confirmed then your code might need to be refactored to avoid duplication.

@seanmcleod70

Copy link
Copy Markdown
Contributor

@m-tra can you type up a summary of what changes you had to make relative to the current piston engine implementation for diesel specific modelling? As opposed to us having to manually try and diff the source code to figure out the differences.

I'm not sure if you realize that any further commits you push to the branch you used for the pull request automatically flow into the PR. So for example your latest commit - "commits for the day" are now included in the PR.

You should only be pushing commits to the branch you used for the PR if they are specific to this PR. If you want to continue working on additional features that aren't ready or aren't really part of the point of the PR then you should be doing that in a separate branch.

@m-tra
m-tra marked this pull request as draft April 16, 2026 07:55
@m-tra
m-tra force-pushed the master branch 3 times, most recently from ac0044e to 333e98d Compare April 19, 2026 15:15
@m-tra

m-tra commented Apr 19, 2026

Copy link
Copy Markdown
Author

Hi, thanks for you comments.

I've cleaned up the commits history and here are the main changes :
I've created a FGPistonDiesel similar to the original FGPiston class :

What's removed from the piston model:

  • Mixture control and magnetos/spark ignition system — diesels use compression ignition, so none of this applies
  • Spark-fail modeling

What's added/replaced:

  • Fuel rack replaces mixture — throttle controls fuel injected per stroke rather than an air butterfly
  • Glow plug system for cold starting (replaces spark plugs). The basis for the implementation is there, but not modeled as this was not the focus of this project.
  • Coolant temperature tracking : the target engine (PSA TUD3) is liquid-cooled, unlike typical air-cooled aviation gas engines
  • Injection type parameter (, e.g. IDI)
  • Torque curve control via new and XML parameters, since diesels peak torque at much lower RPM than max RPM
  • Different defaults — compression ratio 22:1 (vs 8.5), different FMEP friction values reflecting diesel mechanical characteristics
  • New engine type etPistonDiesel in the enum, triggered by <diesel_engine> XML tag

What's unchanged: Airflow calculations, oil system, CHT modeling, and supercharger/turbo framework are largely carried over from FGPiston. I acknowledge there's significant duplication

I'm open to discussion on refactoring into a shared base class. Turbo support is minimal since our project focused on a naturally aspirated engine.

Integration: Updated FGPropulsion, FGEngine.h, FGJSBBase.h, JSBSim.cpp, FlightGear interface, Unreal Engine plugin, Python bindings, and build files. Included a complete Gaz'Aile example aircraft with the PSA TUD3 engine (~52 hp, 4-cyl IDI diesel).

@m-tra
m-tra marked this pull request as ready for review April 19, 2026 15:23
@codecov

codecov Bot commented Apr 26, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 0% with 699 lines in your changes missing coverage. Please review.
✅ Project coverage is 24.21%. Comparing base (dc4396c) to head (03d10e8).
⚠️ Report is 8 commits behind head on master.

Files with missing lines Patch % Lines
src/models/propulsion/FGPistonDiesel.cpp 0.00% 685 Missing ⚠️
src/models/FGPropulsion.cpp 0.00% 7 Missing ⚠️
src/models/propulsion/FGPistonDiesel.h 0.00% 7 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1432      +/-   ##
==========================================
- Coverage   25.11%   24.21%   -0.91%     
==========================================
  Files         169      171       +2     
  Lines       18721    19420     +699     
==========================================
  Hits         4702     4702              
- Misses      14019    14718     +699     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new compression-ignition piston engine implementation (“diesel engine”) to the propulsion system, wires it into engine loading/bindings, and includes a sample aircraft/script plus integration updates (FlightGear example + Unreal plugin). Also updates the Python logger behavior (level filtering) with a new regression test and adjusts Python stub generation for certain default-value expressions.

Changes:

  • Introduce FGPistonDiesel engine model and integrate it into propulsion loading/build configuration.
  • Update bindings/integrations to recognize the new engine type (core enum, FlightGear example, Unreal plugin).
  • Update Python logger enums/logger filtering + add a Python test; tweak pyxstubgen for attribute-style default values.

Reviewed changes

Copilot reviewed 25 out of 27 changed files in this pull request and generated 13 comments.

Show a summary per file
File Description
tests/TestPythonDefaultLoggerFiltering.py New Python test validating default logger filtering behavior.
tests/CMakeLists.txt Registers the new Python test in the test list.
src/models/propulsion/FGPistonDiesel.h New diesel piston engine class API, configuration docs, and runtime state.
src/models/propulsion/FGPistonDiesel.cpp New diesel engine implementation: airflow, fuel rack/governor, turbo, temps, oil system, property bindings.
src/models/propulsion/FGEngine.h Adds etPistonDiesel engine type to the global engine enum.
src/models/propulsion/CMakeLists.txt Adds diesel engine sources/headers to the build.
src/models/FGPropulsion.cpp Loads <diesel_engine> configs and updates property binding logic.
src/FGJSBBase.h Adds intom conversion constant used by the diesel model.
scripts/gazaile_elevation_test.xml New runscript for the added sample aircraft.
python/pyxstubgen.py Extends stub generation to handle attribute-access expressions as default values.
python/jsbsim.pyx.in Changes several enums to IntEnum; adds min-level filtering to DefaultLogger.
examples/FlightGear.cxx Extends engine state export to FlightGear properties for diesel engines.
aircraft/gazaile/thumbnail.jpg Adds sample aircraft thumbnail asset.
aircraft/gazaile/reset00.xml Adds initial-condition file for the sample aircraft.
aircraft/gazaile/gazaileap.xml Adds autopilot test configuration for the sample aircraft.
aircraft/gazaile/gazaile.xml Adds full sample aircraft configuration referencing the new diesel engine.
aircraft/gazaile/Engines/GazAile_Prop.xml Adds propeller definition for the sample aircraft.
aircraft/gazaile/Engines/GazAile_Engine.xml Adds diesel engine XML config using <diesel_engine>.
aircraft/gazaile/Engines/GazAile_Elec_Engine.xml Adds an electric engine config (sample/alternate).
aircraft/gazaile/.gitkeep Ensures the new aircraft directory is retained in source control.
UnrealEngine/Plugins/JSBSimFlightDynamicsModel/.../Public/FDMTypes.h Adds PistonDiesel to Unreal-facing engine type enum + minor formatting cleanup.
UnrealEngine/Plugins/JSBSimFlightDynamicsModel/.../Private/JSBSimMovementComponent.cpp Includes FGPistonDiesel and reads diesel-specific state into Unreal structs.
README.md Adds an LGPL badge in the Legal Notice section.
JSBSimForUnreal.vcxproj.filters Adds diesel source file to the Visual Studio filters list for the Unreal build.
JSBSimForUnreal.vcxproj Adds diesel header to the Visual Studio project for the Unreal build.
JSBSim.vcxproj.filters Adds diesel source file to the Visual Studio filters list.
.github/workflows/cpp-python-build.yml Updates softprops/action-gh-release action version.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +692 to +702
target_boost = BoostMaxPressure_Pa * rpm_factor * FuelRack;
}

// Turbo lag - first-order lag on spool-up and spool-down.
double dt = in.TotalDeltaT;
CurrentBoost_Pa += (target_boost - CurrentBoost_Pa)
* (1.0 - std::exp(-dt / TurboLag_tau));

// Apply boost to intake pressure.
MAP = p_amb + CurrentBoost_Pa;

Copilot AI Apr 26, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

boost-max-pressure is documented/treated as an absolute manifold pressure limit (see comments and defaulting to 1.5 bar absolute), but doTurbo() uses it as a delta boost and then adds ambient again (MAP = p_amb + CurrentBoost_Pa). This can overshoot the intended absolute limit by ~1 bar at sea level. Either store CurrentBoost_Pa as absolute pressure and assign MAP = CurrentBoost_Pa, or treat BoostMaxPressure_Pa as max delta above ambient and update docs/defaulting accordingly (e.g., clamp MAP to BoostMaxPressure_Pa).

Copilot uses AI. Check for mistakes.

// Airbox impedance correction
if (Z_airbox > 0) {
double airbox_loss = Z_airbox * m_dot_air;

Copilot AI Apr 26, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Airbox impedance correction currently uses m_dot_air before it is computed for the current timestep (airbox_loss = Z_airbox * m_dot_air), so the pressure-drop feedback is based on stale state from the previous frame. This will make VE/manifold behavior timestep/order dependent. Use the current-step airflow estimate (e.g., compute a provisional m_dot_air first, or express the loss in terms of v_dot_air/rho_intake).

Suggested change
double airbox_loss = Z_airbox * m_dot_air;
// Use a current-step airflow estimate for the impedance feedback rather than
// the previous frame's m_dot_air value.
double provisional_v_dot_air = swept_volume * ve_base;
double airbox_loss = Z_airbox * provisional_v_dot_air;

Copilot uses AI. Check for mistakes.
Comment on lines +760 to +761
// Clamp VE to sane range
volumetric_efficiency_reduced = Constrain(0.0, volumetric_efficiency_reduced, 1.0);

Copilot AI Apr 26, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

volumetric_efficiency_reduced is clamped to a maximum of 1.0, but the class documentation explicitly notes turbocharged engines may require VE > 1.0. With the current clamp, boosted configurations cannot achieve the documented behavior. Consider increasing the upper clamp (or clamping based on a separate, documented max) when Boosted is enabled.

Suggested change
// Clamp VE to sane range
volumetric_efficiency_reduced = Constrain(0.0, volumetric_efficiency_reduced, 1.0);
// Clamp VE to a sane range. Turbocharged engines may legitimately exceed
// unity volumetric efficiency, so only naturally aspirated engines are
// limited to 1.0.
const double max_volumetric_efficiency = Boosted ? 1.5 : 1.0;
volumetric_efficiency_reduced = Constrain(0.0, volumetric_efficiency_reduced,
max_volumetric_efficiency);

Copilot uses AI. Check for mistakes.
Comment on lines +342 to +344
if (Cooling_Factor < 0.0)
Cooling_Factor = 5.0 * MaxHP;

Copilot AI Apr 26, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Defaulting Cooling_Factor is currently inside the if (BSFC_best < 0.0) block, so providing bsfc-best in XML without an explicit cooling-factor leaves Cooling_Factor at -1 (which flips the sign of radiator/ram-air heat rejection and can heat the coolant/head instead of cooling). Derive a sane default for Cooling_Factor independently of how BSFC is provided.

Copilot uses AI. Check for mistakes.
Comment on lines +845 to 851
if (HavePistonDieselEngine) {
PropertyManager->Tie("propulsion/starter_cmd", this, &FGPropulsion::GetStarter, &FGPropulsion::SetStarter);
}

if (HavePistonEngine) {
PropertyManager->Tie("propulsion/starter_cmd", this, &FGPropulsion::GetStarter, &FGPropulsion::SetStarter);
PropertyManager->Tie<FGPropulsion, int>("propulsion/magneto_cmd", this,

Copilot AI Apr 26, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

propulsion/starter_cmd is tied in both the diesel and piston blocks. If an aircraft ever mixes piston and piston-diesel engines, this will double-tie the same property and likely throw at runtime (similar to the double-tie note in FGPistonDiesel). Tie propulsion/starter_cmd once when either piston type is present (or guard against already-tied properties).

Copilot uses AI. Check for mistakes.
Comment on lines +896 to +900
m_dot_fuel = m_fuel_per_cycle * injections_per_sec; // kg/s
FuelFlow_pps = m_dot_fuel * kgtolb; // lb/s
FuelFlow_gph = m_dot_fuel * 3600.0 / 1000.0; // g/h
FuelFlowRate = FuelFlow_pps; // for CalcFuelNeed

Copilot AI Apr 26, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FuelFlow_gph is being assigned using m_dot_fuel * 3600 / 1000 (commented as g/h), which does not match the meaning of "gallons per hour" used elsewhere in FGEngine/FGPiston (and exposed via getFuelFlow_gph()). This will produce incorrect fuel flow outputs (e.g., FlightGear/FGOutputFG). Compute FuelFlow_pph/FuelFlow_gph consistently with the existing convention (lb/s -> lb/hr, then divide by FuelDensity) or set only FuelFlowRate and rely on GetFuelFlowRateGPH().

Copilot uses AI. Check for mistakes.
if (el->FindElement("peak-torque-rpm"))
PeakTorqueRPM = el->FindElementValueAsNumber("peak-torque-rpm");
if (el->FindElement("bsfc"))
BSFC_best = el->FindElementValueAsNumberConvertTo("bsfc", "LBS/HP*HR");

Copilot AI Apr 26, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<bsfc> is read with units converted to LBS/HP*HR and stored into BSFC_best, but later calculations treat BSFC_best as g/(kW*h) (e.g., fuel_flow_rated_kgs = (BSFC_best * MaxHP_kW) / 3.6e6). This unit mismatch will severely break fuel flow/power calibration whenever <bsfc> is used. Either remove <bsfc> handling for diesel, or convert it into the internal units expected by the diesel model before assignment.

Suggested change
BSFC_best = el->FindElementValueAsNumberConvertTo("bsfc", "LBS/HP*HR");
BSFC_best = el->FindElementValueAsNumberConvertTo("bsfc", "LBS/HP*HR")
* (453.59237 / 0.745699872); // convert lb/(hp*hr) to g/(kW*h)

Copilot uses AI. Check for mistakes.
Comment thread JSBSim.vcxproj.filters
Comment on lines +208 to 211
<ClCompile Include="src\models\propulsion\FGPistonDiesel.cpp">
<Filter>Source Files</Filter>
</ClCompile>
</ClCompile>

Copilot AI Apr 26, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .vcxproj.filters change breaks the XML structure: the new FGPistonDiesel.cpp <ClCompile> entry is nested inside the existing FGPiston.cpp <ClCompile> element (missing a closing tag before the insertion). Visual Studio will fail to load the filters file. Close the FGPiston.cpp <ClCompile> element before adding the new sibling element.

Suggested change
<ClCompile Include="src\models\propulsion\FGPistonDiesel.cpp">
<Filter>Source Files</Filter>
</ClCompile>
</ClCompile>
</ClCompile>
<ClCompile Include="src\models\propulsion\FGPistonDiesel.cpp">
<Filter>Source Files</Filter>
</ClCompile>

Copilot uses AI. Check for mistakes.
Comment thread tests/TestPythonDefaultLoggerFiltering.py
Comment thread tests/TestPythonDefaultLoggerFiltering.py
@bcoconni

Copy link
Copy Markdown
Member

Thanks again for your valuable contribution @m-tra.

There are a number of topics to address

GitHub Copilot review

Since the PR is quite beefy, I have requested a review from GitHub Copilot.

Please address its comments. When they are irrelevant, please state clearly why.

XML Validation failure

I have also launched the CI workflow which fails because the XML validation of the file aircraft/gazaile/gazaile.xml fails:

aircraft/gazaile/gazaile.xml:80: element location: Schemas validity error : Element 'location', attribute 'name': The attribute 'name' is not allowed.
aircraft/gazaile/gazaile.xml:167: element location: Schemas validity error : Element 'location': This element is not expected. Expected is one of ( description, feed, thruster ).
aircraft/gazaile/gazaile.xml:740: element system: Schemas validity error : Element 'system': This element is not expected. Expected is one of ( input, output ).
aircraft/gazaile/gazaile.xml fails to validate

Please fix these errors.

Error in the script

The script scripts/gazaile_elevation_test.xml fails with the following error:

In file scripts/gazaile_elevation_test.xml: line 102
FGPropertyValue::GetValue() The property propulsion/engine[0]/coolant-temperature-degK does not exist

Please fix this error.

Merge conflicts

The file python/pyxstubgen.py is in conflict with the official master branch.

Please fix it. One easy way to address this is to copy/paste the file from GitHub (click on the icon "Copy raw file" from https://github.com/JSBSim-Team/jsbsim/blob/master/python/pyxstubgen.py)

Files cleanup

  • Please remove the file aircraft/gazaile/.gitkeep
  • Please remove the thumbnail aircraft/gazaile/thumbnail.jpg. Images are limited to documentation to keep the repo size reasonable.

Unreal Engine update

@gallonmate Could you please review the modifications that this PR makes to the Unreal Engine plugin ?

@seanmcleod70

Copy link
Copy Markdown
Contributor

Maybe we should ask CoPilot for a comparison between?

  • FGPiston class with a sprinkling of if/else statements for diesel/non-diesel calcs
  • New common base class
  • Current PR structure

@bcoconni

Copy link
Copy Markdown
Member

@seanmcleod70 done!

Copilot Chat Conversation Export: Design recommendations for engine class structure

User: @bcoconni
Thread URL: https://github.com/copilot/c/775c0562-cace-48ad-a2cb-cfebdbaaa91d

@bcoconni

Although the PR #1432 in attachment is adding a brand new engine model to JSBSim, it seems to have quite a number of commonalities with the piston model in src/models/propulsion/FGPiston.*. Could you review the PR especially focusing on a comparison between:

  • Using the FGPiston class with a sprinkling of if/else statements for diesel/non-diesel calcs
  • Using a new common base class
  • Keeping the current PR structure

Copilot

I would not put this into FGPiston with diesel/non-diesel if/else branches, and I also would not merge it as-is with the current structure. The best direction is a new common base class / shared internal helper layer, with FGPiston and FGPistonDiesel as separate concrete engine models on top.

The reason is simple: the PR demonstrates that diesel and gasoline piston engines are structurally similar at the integration boundary, but materially different in core physics and controls.

My recommendation

  • Short term for this PR: keep separate classes, but ask for a refactor that extracts the duplicated scaffolding into shared code before merge, or as a prerequisite follow-up if you want to reduce scope.
  • Long term design: introduce something like FGRecipEngineBase / FGPistonBase for common reciprocating-engine mechanics, state, lifecycle, bindings, and reporting; keep gasoline and diesel thermodynamic/control logic in separate derived classes.

Why not fold diesel into FGPiston with conditionals?

Because the commonality is mostly in:

  • engine lifecycle
  • some temperature/oil plumbing
  • property binding patterns
  • thruster interaction
  • labels/values/reporting
  • XML loading shape

But the real behavior differs in exactly the places that dominate code complexity:

  • Startup model

    • gasoline uses magnetos and mixture (FGPiston::doEngineStartup, magneto logic)
    • diesel uses fuel-only self-ignition plus starter/governor logic, no magnetos
  • Air path

    • gasoline uses throttle-controlled manifold pressure and optional supercharger logic
    • diesel is fundamentally unthrottled and fuel-metered; turbo behavior is different in meaning and control
  • Fueling

    • gasoline: mixture lever and AFR/equivalence driven by throttle + mixture
    • diesel: fuel rack, smoke limit, governor droop, idle governor, cold enrichment
  • Power production

    • gasoline power path in FGPiston is based on ISFC/mixture efficiency and pumping losses
    • diesel path is based on injected fuel energy, indicated efficiency calibration, IMEP/BMEP/FMEP
  • Thermals

    • current FGPiston is clearly air-cooled biased
    • diesel PR adds liquid cooling and thermostat behavior

Once you add:

  • if (diesel) doFuelRack() else doMixtureFuelFlow()
  • if (diesel) doTurbo() else doBoostControl()+doMAP()
  • if (diesel) startup without spark else startup with magnetos
  • if (diesel) coolant model else no coolant model

FGPiston stops being “the gasoline piston model” and becomes “all reciprocating engines with lots of mode flags,” which is exactly the kind of class that becomes hard to validate and easy to regress.

Why a common base class is the best design

Because there is obvious duplicated scaffolding between the two classes already.

Examples of overlap:

  • ctor flow: Load(...), defaults, config parsing, table parsing, post-read derivations, property tying
  • ResetToIC()
  • Calculate() orchestration shape
  • CalcFuelNeed()
  • InitRunning()
  • oil temperature/pressure concepts
  • CHT/EGT concepts
  • GetEngineLabels() / GetEngineValues()
  • debug output structure
  • many identical or near-identical state members

That overlap is real enough that the current PR is paying a high duplication cost. But it’s not the kind of overlap that argues for one giant condition-driven class; it argues for shared abstraction below, separate models above.

A good split would be:

Shared base owns

  • common reciprocating-engine state:
    • displacement, bore, stroke, cylinders, RPM, HP, airflow/fuelflow outputs, temperatures, oil pressure, etc.
  • common lifecycle:
    • ResetToIC
    • CalcFuelNeed
    • top-level Calculate skeleton
    • thruster interaction
    • property binding helpers
    • debug/reporting helpers
  • common utilities:
    • unit conversions
    • mean piston speed
    • oil system helper
    • label/value formatting

Gasoline subclass owns

  • magnetos
  • throttle/MAP model
  • mixture/fuel flow logic
  • supercharger boost-speed model
  • gasoline-specific combustion efficiency and pumping model

Diesel subclass owns

  • governor/fuel-rack logic
  • smoke limit
  • diesel startup/self-sustain logic
  • turbo lag / boost behavior
  • liquid cooling and glow-plug/cold-start behavior

That keeps each engine model coherent and testable.

Why I would not keep the PR structure unchanged

The current PR structure proves the concept, but it is too copy-paste heavy and it is already showing the usual duplication drift problems.

The review comments already caught several examples of this:

  • turbo pressure semantics inconsistent with docs/implementation
  • stale-state use in airflow impedance
  • duplicated property tie risk in FGPropulsion
  • getter name mismatch in Unreal integration
  • unit mismatch on bsfc
  • fuel flow naming/meaning inconsistency
  • cooling-factor defaulting tied to unrelated BSFC branch

Those are not random bugs; they’re exactly what happens when a large sibling class is forked from an existing one and then evolves independently.

So while “keep the current PR structure” is better than stuffing everything into FGPiston, I still think it is not the ideal end state.

My ranking of the three options

1. New common base class — best

Best balance of:

  • maintainability
  • conceptual clarity
  • future extension (e.g. rotary, two-stroke variants, FADEC diesel, alt diesel cooling models)
  • lower regression risk than conditionals
  • less duplication than current PR

2. Current PR structure — acceptable as an interim step, not ideal as final architecture

Pros:

  • preserves conceptual separation
  • avoids contaminating FGPiston with incompatible concepts
  • easier to review behaviorally

Cons:

  • too much duplication
  • duplicated bug fixes later
  • integration/reporting/property APIs will drift
  • higher maintenance burden

If merged in roughly this form, I’d want an explicit follow-up issue to extract the common reciprocating-engine scaffolding.

3. Use FGPiston with diesel/non-diesel if/else — worst

Pros:

  • less file count
  • some duplication eliminated

Cons:

  • one class with two different engine-control philosophies
  • harder reasoning and testing
  • higher chance of regressions in mature gasoline behavior
  • more configuration branches and “impossible states”
  • future changes become harder, not easier

Concretely, what I’d ask the author to do

If you want the best architecture now:

  • extract a shared reciprocating-engine base/helper layer first
  • keep FGPiston and FGPistonDiesel separate subclasses

If you want to land functionality faster:

  • keep separate classes for now
  • but reduce obvious duplication immediately:
    • shared property-binding helpers
    • shared oil system code if behavior is intended to match
    • shared reporting/debug code
    • shared common-state struct or base members
  • and fix the correctness issues already raised in review before merge

Merge/readiness view tied to the architecture question

From an architecture standpoint, the PR is directionally right in choosing a separate diesel class instead of mutating FGPiston.
From a codebase-maintenance standpoint, it is not yet in the right final form, because the duplication is too large and is already producing correctness and consistency defects.

So my review answer is:

  • Do not fold diesel into FGPiston with conditionals.
  • Prefer a shared base class/shared reciprocating-engine layer.
  • If that’s too much for this PR, the current separate-class approach is still preferable to conditionals, but it should not be considered the finished design.

@gallonmate

Copy link
Copy Markdown
Contributor

@gallonmate Could you please review the modifications that this PR makes to the Unreal Engine plugin ?

@bcoconni Besides the coolant temperature issue that Copilot found, the diesel addition to Unreal plugin should be fine. 👍

(It might need diesel added to the switch statement in the function below, but can fix that later if it causes a problem.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants