Benjamin Moir

I used it for parity with how the host filesystem implementation in IopBios interprets the paths (i.e., it treats `host:`, `host0:`, `host1:`, `host2:`, etc.., identically). If it's preferred, I can...

I've changed it to use the existing `is_host` and `host_path` functions from IopBios (the latter being moved from `::R3000A` to `::R3000A::ioman` for extra consistency now that it's exposed via header).

@ds5678 That sounds fine to me. Feel free to make that change if you have the time, otherwise I will get around to it sometime later.

@0x900x90 > > > I tried to build this project. Got some errors. I removed 2019 TypeTree's because i got CS0208 errors on them. > > CS0208 - "Cannot take...

> > > Compilation error CS0208 happens in TypeTree.V2019_1.cs > > internal struct TypeTree > { > public TypeTreeShareableData* Data; public TypeTreeShareableData PrivateData; > } > Yeah, this is because...

If you change this line: https://github.com/DaZombieKiller/TypeTreeDumper/blob/f9d75f3ecdc0adf502ea3b45f9e8c92c468c2b6d/Unity/RuntimeTypes.cs#L56 to this: ```cs ClassIDToRTTI = resolver.ResolveFunction( "?ClassIDToRTTI@Object@@SAPEAURTTI@@H@Z", "?ClassIDToRTTI@Object@@SAPAURTTI@@H@Z" ); ``` Does it work?

The unresolved symbol errors should now be fixed in https://github.com/DaZombieKiller/TypeTreeDumper/commit/7996e0af87c44f20d8d4b1791db6074fb76a6f3d.

> I fixed this function name `??0UnityVersion@@QAA@PBD@Z` > In the most recent commit (https://github.com/DaZombieKiller/TypeTreeDumper/commit/7996e0af87c44f20d8d4b1791db6074fb76a6f3d) I introduced `NameMangling.Ptr64` to fix cases like this, which changes the symbol string to `$"??0UnityVersion@@Q{NameMangling.Ptr64}AA@P{NameMangling.Ptr64}BD@Z"` instead...

I see, so there's a `__thiscall` variant of it. It might be worth changing it to `$"??0UnityVersion@@QAE@P{NameMangling.Ptr64}BD@Z"` to support both x86 and x64 at the same time then. I'll do...

I took a quick look through the code, and I saw an issue that could be causing stalls: `Produce` was changed to take `in byte` instead of `in RuntimeTypeInfo`. `in`...