Question Testing Linux/Mac & Windows Paths for Mesh and Texture files

[Thunder Chicken]

I had high hopes that my J-3 add-on would be OS agnostic, but I forgot that there are a couple instances where I needed to specify folder pathways, and that IS OS dependent. In particular, when I load the mesh I have this command:

hmesh = oapi.load_mesh_global('J-3/J-3')

which works on Linux (what I am running) and I think it works on Mac, but it may not work on Windows which needs the backslash:

hmesh = oapi.load_mesh_global('J-3\J-3')

This won't run on Linux, but it works on my Linux box with a second escape backslash:

hmesh = oapi.load_mesh_global('J-3\\J-3')

There are also folder paths specified inside the mesh file for referencing the textures in Textures that already seem to be in Windows format which already works fine.

TEXTURES 7
J-3\j-3_panel_switches.dds
J-3\lightning.dds
J-3\cub_yellow.dds
J-3\tail_logo.dds
J-3\wing_number.dds
J-3\rudder_number.dds
J-3\compass_wheel.dds

I don't have access to a Windows box so I don't know what will work or not. But I'd like to make this vessel script OS independent if I can. I know I can simply get rid of the J-3 subfolders for textures and meshes, but I really would like to keep the mesh and textures in their own folders to keep things organized, but I'll do that if it is 100% necessary. I think the textures are being referenced by Orbiter so the path formatting inside the mesh file for them is fine, but I think I need to test if the mesh is loaded properly in some way.

The oapi.load_mesh_global method for Lua is somewhat confusing because this command is actually found as oapi.load_meshglobal in the Lua interpreter code on GitHub, but that doesn't run for me unless I put the second underscore in? There is also no documentation that I can find indicating whether anything is passed by this method in the event the file is not read. If I can detect if the file was not read, then I can put it in an if...then structure where the other path format can be used.

 

[Gondos]

Slashes work perfectly fine on Windows boxes. The linux experiment is patching paths to replace backslashes with slashes anyway.

 

[kuddel]

As @Gondos noted, slashes are "accepted" in almost every environment.
Drive letters ( "C:\" for example) are a different thing as they are only a Windows-thing (DOS as well if you like). But that's no issue when using only relative paths.

If you really want to make it portable across all platforms you have to take look at filesystem libray/header (std::filesystem:ath in particular) - the resulting code however tends to be very verbose, so usually I don't use it very often.

 

[Thunder Chicken]

As @Gondos noted, slashes are "accepted" in almost every environment.
Drive letters ( "C:\" for example) are a different thing as they are only a Windows-thing (DOS as well if you like). But that's no issue when using only relative paths.

If you really want to make it portable across all platforms you have to take look at filesystem libray/header (std::filesystem:ath in particular) - the resulting code however tends to be very verbose, so usually I don't use it very often.

I understand that now. I thought it may have been a problem with this script on another OS, but it turns out the problem was that I was using this command:

hmesh = oapi.load_mesh_global('J-3\J-3')

which apparently was only the name of that command for a couple of OpenOrbiter versions until it was changed to

hmesh = oapi.load_meshglobal('J-3\J-3')

to better align with the names of the C++ API methods. It confused me greatly until I figured out that that occurred. I've resolved this point of confusion and have moved on to newer, more confusing ones.

 

[Gondos]

As @Gondos noted, slashes are "accepted" in almost every environment.
Drive letters ( "C:\" for example) are a different thing as they are only a Windows-thing (DOS as well if you like). But that's no issue when using only relative paths.

If you really want to make it portable across all platforms you have to take look at filesystem libray/header (std::filesystem:ath in particular) - the resulting code however tends to be very verbose, so usually I don't use it very often.

std::filesystem is no silver bullet, in my experience it provides only code portability, not OS agnostic paths.
The same goes with text mode file access which handles new lines differently across platforms.