load() and MultiplayerSpawner Cause Unexpected Replication Behavior

[TimothyAlba]

Tested versions

• Reproducible in: 4.3-stable, 4.5.1-stable

System information

Godot v4.5.1.stable - Windows 11 (build 26100) - Multi-window, 2 monitors - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 Ti (NVIDIA; 32.0.15.8157) - AMD Ryzen 9 7900X3D 12-Core Processor (24 threads) - 31.11 GiB memory

Issue description

Expected

If function load() is able to load a given scene with the incorrect case then MultiplayerSpawner configured with the correct case will spawn the scene to clients when the node is added to the MultiplayerSpawner's spawn path.

Actual

Something in the metadata load() adds to the PackedScene carries the incorrect case of the loaded scene's name, and thus when the instantiated node is added to the MultiplayerSpawner's spawn path the MultiplayerSpawner does not recognize the node's scene as a scene to replicate to clients.

First noticed it in 4.3-stable which would output a light warning in the debug console like so

0:00:06:0928   game.gd:4 @ _ready(): Case mismatch opening requested file 'res://scenes/core/player/player.tscn', stored as 'res://scenes/core/player/Player.tscn' in the filesystem. This file will not open when exported to other case-sensitive platforms.
  <C++ Source>   drivers/windows/file_access_windows.cpp:181 @ open_internal()
  <Stack Trace>  game.gd:4 @ _ready()

The above warning does not show in 4.5.1-stable

Proposal

Either:

• Throw a runtime error when there's a case mismatch in the load() function
• Fix the case mismatch when creating the PackedScene so it contains the correct case

Steps to reproduce

Recreate Failure

1. In res://scripts/lobby.gd ensure line 9 is commented out and line 7 is uncommented
2. Start the game with at least two debug windows
3. On one window click Host
4. On the other windows click Join
5. Check the Remote tab in the Scene window, clicking through the different sessions and notice how only one of the sessions has nodes in the root/Game/Lobby/Players path

Working Version

1. In res://scripts/lobby.gd ensure line 7 is commented out and line 9 is uncommented
2. Start the game with at least two debug windows
3. On one window click Host
4. On the other windows click Join
5. Check the Remote tab in the Scene window, clicking through the different sessions and notice how all sessions now have nodes in the root/Game/Lobby/Players path

Minimal reproduction project (MRP)

Godot-load-bug.zip

[AThousandShips]

If function load() is able to load a given scene with the incorrect case

It isn't though, it warns in the editor and fails when running, as the warning states

You should just fix the incorrect path I'd say, the editor shouldn't just change your input itself IMO

Arguably a duplicate of:

• MultiplayerSpawner does not autospawn the autospawn list path due to case sensitivity #107558

[TimothyAlba]

It isn't though, it warns in the editor and fails when running, as the warning states

Incorrect, it does not fail when running on Windows.

You should just fix the incorrect path I'd say, the editor shouldn't just change your input itself IMO

I agree but this conclusion should arise from a runtime error during development where it can't find the file, not after someone spends hours trying to figure out what is wrong. There's no reason for the engine to resolve case-sensitivity in the file access if other parts of the engine won't handle it in the same fashion, creating an unexpected state as described in my issue above. The correct solution here is to let the file access fail in finding the file, causing a descriptive error to be thrown which is easier to debug rather than a warning which stops printing in Godot versions later than 4.3-stable.

I've verified in both Godot 4.4.1-stable and 4.5.1-stable the warning does not print in the debug console. Not sure why and I've not changed any of my settings in 4.3-stable to be more verbose, thus I can only assume something somewhere downstream in the stack is handling the case insensitivity.

I will agree this is a duplicate of the one you linked, so I will post my comment over there to continue the discussion as this is not a good way to handle case mismatch and is unintentionally creating unexpected behaviors in other parts of the engine.

[TimothyAlba]

What I think is happening is a case-insensitive OS will return the file to the engine and the engine will assume the file path is correct, and therefore will add the path as is to the metadata of the PackedScene. The assumption here is the engine is running on a case-sensitive OS when it is known there are case-insensitive OS and so the file path provided by the developer shouldn't be trusted. Instead the file access code should (if possible) query the OS for the correct path and use the OS provided path instead, or better yet throw a runtime error if the two paths are not equal which would prevent future developer bugs due to case issues.

[AThousandShips]

Incorrect, it does not fail when running on Windows.

It will when running the exported project

This is solved by having additional checks for invalid paths and suggesting that they be fixed, but the engine shouldn't "fix" the path itself, it should prompt the user to fix it

[Radin8877]

Overly verbose TLS errors in Asset Library browsing

Issue description

When browsing the Asset Library, some assets have icons hosted on domains with invalid TLS certificates or expired SSL. Godot prints verbose TLS handshake errors to the console which are unnecessary for end users.

Reproducible examples

1. Asset 2458 (2090s Language System)

   • Icon URL: https://2090s-gamestudio.de/wp-content/uploads/2023/12/Language_system_icon.png
   • Problem: SSL certificate expired (verified with curl)
   • Error in Godot: TLS handshake error: -9984 and mbedtls error: returned -0x2700

2. Asset 2995 (XR Fragments)

   • Icon URL: https://xrfragment.org/example/assets/logo.png
   • Problem: 404 Not Found (icon doesn't exist)

System information

• Godot versions: 4.3.stable, 4.4.beta4
• OS: Fedora Linux 41, but issue is platform-agnostic

Steps to reproduce

1. Open Asset Library in Project Manager
2. Search for "XR Fragments" (ID 2995) or "2090s Language System" (ID 2458)
3. Check terminal/output for TLS errors

Proposed solution

• Make TLS handshake errors verbose-only in Asset Library context
• Implement graceful fallback for failed icon loading
• Suppress network errors for non-critical asset metadata loading

Additional context

The errors are technically correct but create noise for regular users just browsing the asset library. The surface for such errors is high since icons are sourced from external domains.

[AThousandShips]

@Radin8877 This is completely unrelated, please do not add random comments on issues