cjab / libeq Goto Github PK

In working on my little Godot hobby project, I decided I wanted to allow the user to selectively get files from an S3D. In the current implementation of EqArchive, the entire archive is decompressed.

After trying various ways to add the functionality I wanted to EqArchive, I gave up and just made a new struct for this purpose, as I wanted to move on with my project.

Take a look - I don't think this is an ideal solution (two different structs) but it works for now and I will revisit this later.

4b0e79b

Making an issue here because I started on this and hit a wall and would like to return at some point.
I started an update to AlternateMesh here: https://github.com/bryab/libeq/tree/pr/alternatemesh2
But I can't make sense of the "Face" entry which differs from Mesh. When attempting to render these meshes, I have been unable to create valid faces.

Above are the 0x2c meshes in gequip lined up horizontally. I am here attempting to use the first 3 values of the data field in Face as the face vertices - but as you can see it does not work.

Just putting a pin in this - as this panic is getting hit in the phase4 gequip

I have a folder that I have extracted wld fragments in, but when I try to run the create command it says this:

C:\git-libeq\libeq\target\debug>wld-cli.exe create globalfroglok2_chr output\globalfroglok2_chr.wld
CREATE: "globalfroglok2_chr" -> "output\globalfroglok2_chr.wld"
thread 'main' panicked at 'Could not open source file: globalfroglok2_chr: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }', tools\wld-cli\src/main.rs:246:41
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

I did everything I could to make the folder accessible. It doesn't seem like the folder is the problem.

Possibly this line

let mut reader = File::open(source).expect(&format!("Could not open source file: {}", source));

Is it possible that "File::open" is for opening individual files and not a folder?

I am using wld-cli 0.1.0.

I am trying to figure out how to deal with the fact that many strings in these files are either invalid utf-8 (and encoded in some other format?) or are simply not strings at all.

Take feerrott for example. Its main string hash has invalid utf8; it will fail to load altogether.
For feerrott_obj, the animated fire texture's TextureFragmentEntry's "file_name" parameter is an invalid string.

I'd love to try to figure this out - what tools did you use for examining these files?

It seems many of the _obj files fail at this line (I saw it on eastkarana_obj.s3d too)

ERROR: [RUST] file 'D:\dev\godot\eq_wld\src\parser\mod.rs' at line 295: panic occurred: "called `Result::unwrap()` on an `Err` value: Error(([], Eof))"

https://github.com/cjab/eq_wld/blob/e66e12230a4ceb64c8428c6e48a13d5a3f27aeff/src/parser/mod.rs#L295

The test frag for MeshFragment has an empty Data9. This field:
https://github.com/cjab/eq_wld/blob/13ae91d685501ffe7a6b6b9ead63d1113dd471a2/src/parser/fragments/mesh.rs#L189

global_chr.wld has meshes with this data in it, and it fails to parse.
The documentation is confusing here:
https://github.com/EQEmu/eqemu-docs-v2/blob/main/docs/server/zones/customizing-zones/wld-file-reference.md#data9type--word

It seems to state that the last element in this entry determines whether previous elements exist. But how could that work?

Do you have a good way of extracting fragments out of WLDs that are not yet supported? For example, gequip.wld has 0x26 and 0x27 in it (at least) and the wld-cli extract tool fails to extract them.

hello friend, I have been extending this project for a little game thing I'm working on.

I am however not really a Rust guy by any means, and I am using this as an opportunity to learn Rust a bit better. I have a few head-scratchers at the moment as to how to add some features to your library in the Rust-idiomatic way. If you feel like chatting about it, please send me a message.

Otherwise, ignore this and look out for some random stuff getting added to my fork as I continue my meanderings...