ImGui Version Mismatch: BG3SE Compilation Errors

by Pedro Alvarez 49 views

Hey everyone! I'm diving into a tricky compilation error I encountered while working on the BG3SE (Baldur's Gate 3 Script Extender) project. It seems like there's a version mismatch happening with ImGui, and I'm hoping some of you brilliant minds can help me sort it out. Let's break it down!

Problem Description

So, here's the deal. When I try to build the BG3SE project, the compilation throws a bunch of errors. The main theme of these errors? Undeclared ImGui identifiers. This strongly suggests that the code generated is expecting certain ImGui features or constants that aren't available in the ImGui version I'm using. It's like trying to speak a language with words that haven't been invented yet – the compiler just gets confused.

Error Details

To give you a clearer picture, here are some of the specific errors I'm seeing:

error C2065: "ImGuiStyleVar_ImageBorderSize": undeclared identifier
error C2065: "ImGuiStyleVar_TabBarOverlineSize": undeclared identifier
error C2065: "ImGuiCol_TextLink": undeclared identifier
error C2065: "ImGuiCol_NavCursor": undeclared identifier
error C2065: "ImGuiChildFlags_Borders": undeclared identifier
error C2065: "ImGuiTreeNodeFlags_SpanLabelWidth": undeclared identifier
error C2065: "ImGuiItemFlags_NoTabStop": undeclared identifier
error C2065: "ImGuiItemFlags_NoNav": undeclared identifier
[... and several more similar errors]

These errors all point to the same root cause: the compiler can't find these ImGui identifiers. This could be due to a mismatch in versions, missing configurations, or incorrect mappings in the generated code. As developers, encountering errors is a common part of the journey, and understanding these errors is crucial for effective debugging. This specific issue seems to revolve around how the BG3SE project interacts with the ImGui library, a popular tool for creating user interfaces. The identifiers mentioned in the errors, such as ImGuiStyleVar_ImageBorderSize and ImGuiCol_TextLink, are constants and flags defined within ImGui. When the compiler can't find these identifiers, it indicates that the code is trying to use features or styles that are either not present in the version of ImGui being used or are not correctly exposed in the project's configuration. The situation is further complicated by the fact that the ImGui header file, which should define these identifiers, shows version 1.90.9. This suggests that the correct version of ImGui is being included in the project, yet the compiler still can't resolve the identifiers. This discrepancy raises several possibilities, including issues with the build process, incorrect compiler settings, or problems with the generated code itself. To effectively troubleshoot this issue, it's essential to delve deeper into the project's build configuration, examine the generated code for any potential errors, and ensure that all dependencies are correctly linked. By systematically addressing these factors, developers can identify the root cause of the compilation errors and implement the necessary fixes to resolve the ImGui version mismatch.

Environment

To give you some context, here's my setup:

  • Project: BG3SE (Baldur's Gate 3 Script Extender)
  • File: Enumerations.inl (this file is auto-generated)
  • ImGui header: Shows version 1.90.9
  • Platform: Windows, using Visual Studio

What I've Tried

I've already done some digging to try and fix this myself. Here's what I've checked:

  • Verified ImGui version: I made sure the ImGui header I'm using does indeed say it's version 1.90.9.
  • Checked for identifiers: I looked in the header file to confirm that those missing ImGui identifiers are actually supposed to be there.
  • Confirmed error location: The errors are happening specifically during the compilation of that auto-generated Enumerations.inl file.

These steps are crucial in any debugging process, as they help narrow down the potential causes of the issue. Verifying the ImGui version ensures that the project is using the expected library version, which is essential for compatibility. Checking for the identifiers in the header file confirms that the necessary definitions should be available. Identifying the error location to the Enumerations.inl file helps focus the investigation on the code generation process. Despite these efforts, the errors persist, suggesting that the problem may lie deeper within the build process or the generated code itself. One possibility is that the code generation tool is not correctly mapping ImGui constants to the appropriate values, leading to the undeclared identifier errors. Another possibility is that there are inconsistencies in how ImGui is being included or linked in the project. Further investigation into these areas is necessary to pinpoint the exact cause of the issue and implement a solution. Specifically, developers might need to examine the code generation logic, review the project's build settings, and ensure that the ImGui library is correctly linked. By systematically addressing these potential problem areas, it's more likely that the ImGui version mismatch can be resolved, and the BG3SE project can be built successfully.

Question

This is where I'm scratching my head, guys. The errors make it seem like the auto-generated code is trying to use ImGui features that don't exist in my version, even though the header file says it should be 1.90.9. So, what could be going on here?

Here are my initial thoughts:

  1. Version Mismatch: Could there be a mismatch between the ImGui version used to generate the code and the one used for compilation? Maybe the code generator is using a newer version internally?
  2. Missing Configuration: Are there some configuration defines I need to set to enable these newer ImGui features? Perhaps I'm missing a flag or something similar.
  3. Code Mapping Issue: Is there a problem with how the generated code is mapping to ImGui constants? Maybe the mappings are incorrect, leading to these undeclared identifier errors.

Has anyone else run into similar ImGui version mismatch issues with BG3SE, or does anyone have any ideas on how to fix these undeclared identifier errors? Your insights would be a huge help!

When dealing with version mismatches and library dependencies, it's essential to consider several potential causes and systematically investigate each one. The first question about a mismatch between the code generation and compilation versions is a crucial one. It's possible that the tool used to generate the Enumerations.inl file was built against a different version of ImGui than the one currently being used for compilation. This discrepancy could lead to the generated code referencing ImGui features or constants that are not available in the compilation environment. To address this possibility, it's necessary to examine the build process and identify the specific version of ImGui used during code generation. The second question about missing configuration defines is also important. ImGui, like many libraries, may have certain features or functionalities that are enabled or disabled through preprocessor definitions or configuration settings. If the generated code relies on features that are not enabled in the current configuration, it could result in undeclared identifier errors. Checking the project's build settings and ensuring that all necessary ImGui configuration options are enabled is essential. The third question about a code mapping issue raises the possibility of errors in the generated code itself. If the code generation logic incorrectly maps ImGui constants or features, it could lead to references to non-existent identifiers. In this case, examining the code generation tool and the generated code for any potential errors is crucial. Ultimately, resolving this issue likely requires a combination of these approaches: verifying ImGui versions, checking configuration settings, and examining the generated code. By systematically investigating these areas, developers can pinpoint the root cause of the problem and implement the necessary fixes to ensure that the BG3SE project builds successfully.

Indications

The build failed, and I was using the external libraries provided in the readme.

Diagnostic Files

See the error details in the description above.

Steps to Reproduce

No response provided

Expected Behavior

I expected the DLL files to be generated successfully.

Actual Behavior

The build failed at the last dependency of BG3Extender.

In situations where a build fails at the final dependency, it's crucial to consider the entire dependency chain and identify any potential bottlenecks or issues. The fact that the build process reaches the last dependency, BG3Extender, suggests that earlier dependencies are likely being resolved correctly. However, the failure at this stage indicates that there may be a problem specific to BG3Extender or its interactions with other components. One possibility is that BG3Extender has unmet dependencies of its own, such as other libraries or frameworks that are not correctly linked or configured. Another possibility is that there are conflicts between different dependencies, leading to unresolved symbols or other build errors. To diagnose this issue effectively, it's necessary to examine the build log and identify the specific error messages generated during the failure. These error messages can provide valuable clues about the underlying problem, such as missing files, unresolved symbols, or version conflicts. Additionally, reviewing the documentation and dependencies of BG3Extender can help identify any potential requirements or configuration settings that are not being met. It's also worth considering whether there are any known issues or bugs in BG3Extender itself that might be causing the build failure. Checking the project's issue tracker or forums can provide insights into whether other developers have encountered similar problems and how they were resolved. Ultimately, a systematic approach to troubleshooting, including examining build logs, reviewing dependencies, and checking for known issues, is essential to resolving build failures at the last dependency. By carefully investigating these factors, developers can pinpoint the root cause of the problem and implement the necessary fixes to ensure a successful build.