I’ve started work on porting it to Xojo, but it’s a lot of work, and that says nothing about long term maintenance. I know next to nothing about plugin development, so I was wondering if this is something that a Xojo plugin could be built to use instead? I don’t need full access to every class. The example in the repo is probably enough for my needs, though I wouldn’t know for sure until I could really start integrating it into my project.
I’m really just debating between porting the library myself and paying for a plugin to be created, and wondering if a plugin is even possible.
Only way to “use” a C# library which is byte code in C++ code or other native assembly is to Register it as COM object and then talk to it as COM object.
Which is basically the official way to bridge Native code and the Byte code.
If going that way to actually use the C# object then often the best way is to create C# object that uses the Library and register that part for COM. By doing that then you control the interface you want to expose and can affect how it is to make it easier to talk to from COM client such as for example Xojo. So basically a bridge Object.
You could learn enough Rust to create a DLL/dylib/so exporting and exposing your functions to Xojo to use in a DECLARE that could use this rust lib to explore those UAs:
Ok, so since I need Mac support, it sounds like a plugin is off the table. I’d probably have to create a dylib/dll using C# and declare to it. And funnily enough, a Google search about that returns a top result by a Xojo user.
Thank you for the suggestion. CUE4Parse needs its description updated because it supports up to UE 5.5. I need UE 5.0, and the ability to read the pak and utoc files. If I had access to the uasset files, I’d be a lot closer already, as I wrote a UE4 uasset parser in Xojo. But UE5 is pretty different.
I believe porting CUE4Parse makes the most sense given my requirements.
As we can see at the uasset Crate github source, it is 4.10+ ready and updated to explicitly reaching 5.3 UObjects
The Dot.Net is just a bit more “heavy” work and needs some install works registering your COM interfaces after copying your files to the destination machines before instantiation of your wrappers (I’m not a great fan of this model as MS). That’s why I thought about a light and direct way (a DLL in the LIBS folder and gone).
It will probably create the dependency of the dot.Net runtime at the destination target (unless it is all unmanaged code, rare), that can be a bit cumbersome for some Mac users, and adds a dependency and another point of failure (bad installs of this external thing may break your app).
Any way, have nice work building your chosen path.
Yeah, the assets are stored in these two files. As a proof of concept, I’ve successfully used FModel to export uassets, but my uasset parser doesn’t understand the UE5 uasset. So I’ve still got a long way to go.
Yep. The engine is open source too. Luckily in my case the data I need is not encrypted. But even if they were, according to some of the code I’ve seen, the encryption key is stored inside the file itself. You “just” need to know which offset to look at. The encryption is just a casual deterrent really, because even if it’s not in the file, the game will have the key somewhere. I’m not saying it’s trivial to find, but eventually somebody always will.
