Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix level loading #609

Closed
wants to merge 2 commits into from

Conversation

pzychotic
Copy link
Contributor

Pull Request Type

  • GitHub Workflow changes
  • Documentation or Wiki changes
  • Build and Dependency changes
  • Runtime changes
    • Render changes
    • Audio changes
    • Input changes
    • Network changes
    • Other changes

Description

I believe some changes from #591 broke loading levels or anything that loads dynamic libs from hog files (at least on Windows). Instead of loading the new x64 DLLs from d3-win.hog, the old x86 DLLs from the original game data are loaded, which fails spectacularly.

There is this comment still, that isn't true anymore:

Descent3/Descent3/init.cpp

Lines 1504 to 1505 in 3a7c86a

// last library opened is the first to be searched for dynamic libs, so put
// this one at the end to find our newly build script libraries first

Osiris_ExtractScriptsFromHog() will happily overwrite existing entries of foo.dll in OSIRIS_Extracted_scripts with the last loaded temp filename from either d3.hog or any .mn3 file loaded at level start.

Trying to fix the problem, I asked myself: Why do we even load the old dynamic libs at all? We extract both old and new libs to the temp directory, only to ignore the old ones and only load the new ones. We can skip all that and only extract and load the new ones. Which this PR tries to do.

On Linux/Mac we might have a subtle difference. Since the original builds are already x64 and loading the old dynamic libs might just work, without us realizing that we don't load our new/fixed code from d3-linux|mac.hog.

Related Issues

Screenshots (if applicable)

Checklist

  • I have tested my changes locally and verified that they work as intended.
  • I have documented any new or modified functionality.
  • I have reviewed the changes to ensure they do not introduce any unnecessary complexity or duplicate code.
  • I understand that by submitting this pull request, I am agreeing to license my contributions under the project's license.

Additional Comments

Removed all calls to Osiris_ExtractScriptsFromHog() except for our own build d3-<platform>.hog. This prevents extracting the old dynamic libs from the original game data to the temp directory and trying to load them instead of our own newly build dynamic libs.
Also removed a comment about library search order that isn't true anymore.
MAX_LOADED_MODULES was increased after introduction of d3-win.hog to account for the new x64 DLLs being loadad additional to exisiting DLLs from original game data.
@winterheart
Copy link
Collaborator

This issue addressed by #603, one of commits removes extraction from outdated hogs and prevents extraction for already extracted scripts.

@pzychotic
Copy link
Contributor Author

pzychotic commented Sep 27, 2024

Oh, I wasn't aware that we already have a related issue #605 for this and even a fix in #607.

@winterheart Can you please incorporate my 2nd commit from here (a9f335a), since the MAX_LOADED_MODULES limit was increased only to account for the loading old and new libs from hog files, which we don't do anymore.

Duplicate of #603

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.

2 participants