You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have some tests I'm running with pytest, and they don't load my sprites. I've checked and double-checked the paths and everything, so I started debugging ursina internal code.
If I run the program normally, it initializes my game object, with all the setup code, and it loads the sprite textures fine.
If I run a test that imports the game object and runs it, it does not load the sprite texture files.
I'm creating a Sprite object, which is calling load_texture() with no path, the name of the file (with no file extension). I see no difference between os.getcwd() whether I run the program directly or via pytest.
Figuring it was some sort of path thing, I set asset_folder manually, but no matter when I call it, load_textures() does not demonstrate the change if I run code via pytest. If I try to set the asset_folder manually at the earliest entry point, load_textures() still doesn't see the change in its folders
If I move the setting of the folders variable inside load_textures(), it works fine.
def load_texture(name, path=None, use_cache=True, filtering='default'):
if textureless:
return None
if use_cache and name in imported_textures:
return copy(imported_textures[name])
folders = [ # folder search order
application.compressed_textures_folder,
application.asset_folder,
application.internal_textures_folder,
]
_folders = folders
I'm not sure why it was set on file initialization to begin with, so I don't know the full implications of moving it, but it resolves the issue I was having, at least.
The text was updated successfully, but these errors were encountered:
I wanted the search order to be customizable by setting texture_importer.folders. However, since the list is created on module import, it can be incorrect if application.asset_folder is changed after that. I assume this is the source of your problem. I've now changed all the importers to behave the same way (textures, models, etc.) and made sure it uses updated paths each time the function is called. The upside to this is that modifying the paths in the application.py module will just work. The downside is that the folder search order won't be documented since it's inside the function now. However, I don't think that's a huge issue compared to asset loading breaking.
Could you see if your code works with the recent change or not? (Install from GitHub, not PyPi)
The issue I was having appears fixed in the new version. I can hear music and see one of my sprites, which should be enough to confirm that it's working.
I'm hedging because I seem to have some sort of incompatibility with the new version that is causing walls to be drawn over 80 to 90% of the game, which limits my visibility.
I have some tests I'm running with pytest, and they don't load my sprites. I've checked and double-checked the paths and everything, so I started debugging ursina internal code.
If I run the program normally, it initializes my game object, with all the setup code, and it loads the sprite textures fine.
If I run a test that imports the game object and runs it, it does not load the sprite texture files.
I'm creating a
Sprite
object, which is callingload_texture()
with no path, the name of the file (with no file extension). I see no difference betweenos.getcwd()
whether I run the program directly or via pytest.Figuring it was some sort of path thing, I set
asset_folder
manually, but no matter when I call it,load_textures()
does not demonstrate the change if I run code via pytest. If I try to set theasset_folder
manually at the earliest entry point,load_textures()
still doesn't see the change in its foldersIf I move the setting of the
folders
variable insideload_textures()
, it works fine.I'm not sure why it was set on file initialization to begin with, so I don't know the full implications of moving it, but it resolves the issue I was having, at least.
The text was updated successfully, but these errors were encountered: