SRIV Is it hard-coded directly to the game exe?

[Raistin Kane]

Edit edit edit: I've also found I'm not actually writing out the lipsync!

Do you...
A)relate to the fact that your app do not write lipsync data to the new .bnk it create?
or...
B)Mean that the data your extractor fill with the xml lipsync tag isn't actually correct?

 

[Minimaul]

Definitely A.

I'm just now releasing a fixed version.

 

[Raistin Kane]

The vpm file is the packfile manifest. It is basically the header for each packfile so we don't have to read them individually. During development we used zpp files, which were just packfiles of individual zones.

The way I saw this, the game was using the vpm to create "virtual" zone package(zpp_pc) at data\levels\sr3_city\.
The zone package cannot be found? = Game crash.
So I spent (should I say "wasted"?) some days trying to figure out its code.
Today, I just got the idea: let blank out the vpm.
If the game actually use them, it will definitely crash since the file as no data at all.
Result?
Like you already pointed out, the game don't use it and just run fine.

Zone asm use "buffer" object in their container (as my asm do).

<Primitive Name="1608^k4n3_3cb" Type="Buffer" Allocator="0" Flags="0" ExtensionIndex="255" CPUSize="4824" GPUSize="0" AllocationGroup="0" />

When I try to pack my str2_pc and update my asm at the same time (ThomasJepp.SaintsRow.BuildPackfile), the cmd say that I cannot find the said object. ( what mean it cannot update its size).
To be honest, I have no idea what the buffer cpu size should be.
What I do know is that if I remove the buffer, game no more crash when I enter the zone.
But this don't mean that this is fixed.
The regular object of the zone (like the casino) do not show up (this is expected)...
but the one from my zone swap(the saint tower) dont show either.
Not only that, but...
this zone no more contain any collision. ( I just pass through the floor as soon I enter it)

Edit: Finally managed to get good result!
Look like that we also need ~al(always loaded) zone files variant for thing to work.
I placed the files directly to awld_compact.str2_pc, but will have to check if this will also work with a new pack file.
Still we need the buffer object in the asm(it don't work without it) and I don't know what size I should give them.

 

[flow754]

When I try to pack my str2_pc and update my asm at the same time (ThomasJepp.SaintsRow.BuildPackfile), the cmd say that I cannot find the said object. ( what mean it cannot update its size).

This is something that happened to me just yesterday. I knew there was a container named like my STR2 in the ASM, but the BuildPackfile tool kept saying it couldn't find the container. So I built the STR2 without updating the ASM, then used ThomasJepp.SaintsRow.Stream2 to update the ASM "manually", which worked flawlessly.

 

[Admixon]

This is something that happened to me just yesterday. I knew there was a container named like my STR2 in the ASM, but the BuildPackfile tool kept saying it couldn't find the container. So I built the STR2 without updating the ASM, then used ThomasJepp.SaintsRow.Stream2 to update the ASM "manually", which worked flawlessly.

This is how I was able to port flying lava rocks from Gooh but game crashed after a few seconds.

 

[Raistin Kane]

I placed the files directly to awld_compact.str2_pc, but will have to check if this will also work with a new pack file.

Tried to do it over and over again, unstill rage made his way.
Look like the always loaded stock of our zone ABSOLUTELY need to be placed into awld_compact.str2_pc. (unless someone else prove otherwise)
This wouldn't so bad if name of the object inside the ~al.czh and the one given inside the str2/asm container actually matched.
For exemple, the ~al.czh will ask for "hq_helicopter_landing_pad"...
but the file object inside the str2_pc, asm will actullay get a extra ~l2.
Like so: "hq_helicopter_landing_pad~l2"
Ok...I just saw the logic (I think):
All level mesh file must get a ~l2 added to their name if they are inside a always loaded container.
Why?
I don't know.
Then come the fact that some of the effect files that ~al.czh ask for don't even exist.
For exemple, the ~al.czh will ask for "vfx_firehydrant_dth"...
which actullay become "vfx_firehydrant" inside the str2_pc/asm container.
Of course, I said "some of the effect", not all.
If the logic for the lmesh name was obvious, te one for the effect isn't

Still we need the buffer object in the asm(it don't work without it) and I don't know what size I should give them.

Look like the size do not really matter, so a simple 0 value do the job.

This is something that happened to me just yesterday. I knew there was a container named like my STR2 in the ASM, but the BuildPackfile tool kept saying it couldn't find the container. So I built the STR2 without updating the ASM, then used ThomasJepp.SaintsRow.Stream2 to update the ASM "manually", which worked flawlessly.

Nan.
It can find the container without any problem...
It just can't find the buffer primitive (because they aren't physical file inside the str2_pc)
Should be noted that the error message that ThomasJepp.SaintsRow.BuildPackfile give us in the cmd appear to be inversed:

Unable to find primitive "container name" for container "primitive name"

while it should say:

Unable to find primitive "primitive name" for container "container name"

 

[[V] Knobby]

Sorry I've been missing. I'm glad you got it going. Some comments as I go:

This wouldn't so bad if name of the object inside the ~al.czh and the one given inside the str2/asm container actually matched.
For exemple, the ~al.czh will ask for "hq_helicopter_landing_pad"...
but the file object inside the str2_pc, asm will actullay get a extra ~l2.
Like so: "hq_helicopter_landing_pad~l2"

So this is due to level meshes having different lods depending on the lod of the thing. We use ~l2 for always loaded, ~l1 for medium load, and ~l0 for high lod. These are automagically tacked on to the mesh name in order to pick up the proper lod file for the world lod.

Then come the fact that some of the effect files that ~al.czh ask for don't even exist.
For exemple, the ~al.czh will ask for "vfx_firehydrant_dth"...
which actullay become "vfx_firehydrant" inside the str2_pc/asm container.

I can blame the vfx guys for this one. I had lots of this show up tracking down bugs as well. The issue here is the there is a difference between the effect name, vfx name and the vfx filename. The effect may or may not include anything visual(like a sound effect). If it does include a visual effect, the name matches the name in the vfx.xtbl. That itself has a filename field that matches the actual file to read.

	<Effect>
		<Name>VFX_FireHydrant_DTH</Name>
		<VFX>
			<Filename>vfx_firehydrant.effectx</Filename>

Look like the size do not really matter, so a simple 0 value do the job.

I'm surprised by this. So the buffer object is space we allocate for the cobjects. It is a fake filename and we just use this primitive to give us scratch memory. We just set it to num_objects * 4 bytes. If the buffer ends up NULL we won't call the load callback for the zone and if it doesn't exist as a prim we won't recognize the zone at all. A cobject is not a full-blown object, but instead something inside the zone that can't interact or be a target of script. Something like a building is a good example. Unique mesh with a 3d position, but you can't move it or delete it with script. (Technically this is a lie, we do hide cobjects in cutscenes at times, but it's just turning off rendering for them.)

Is there anything else outstanding here?

 

[idlmn]

I don't want to open a new thread and the title reflects the reason for my question best but it differs a bit from that what has been discussed in previous posts.
The reason for my question is the release of Saints Row IV at GOG. The problem is that you need their client GOG Galaxy to change the language of the game otherwise it falls back to english. That's why I would like to know if the language Saints Row IV uses as its default localization is hardcoded into the game's executable or if I can find it somewhere in game files to change it, so that I don't need the game client.

 

[Raistin Kane]

Sorry I've been missing. I'm glad you got it going.

Thank you for taking some of your time to answer me.

I should say that I didn't move any further since my last post.
Using Quantum app, I tried to add a npc group (from a random mission zone file) to the normal lod one of mine.
This caused my character to be "stuck" when being in my zone.
Then I took some time "studying" your post about the zone file format...
https://www.saintsrowmods.com/forum/threads/sr3-zone-file-format.2855/
This obviously ended up by me "stopping by lost of interrest".

Today, I decided to give it a another try.
This time, I attended to add one of the zombie group from mol_mm mission to my ~al zone file.
Result: character isn't stuck!
I added a group_create function to my lua and a another one that pop-up a message if the member of the group exist.
Result: They do!
I added teleport so all the group member teleport to me.
It worked...
but they were just staring at me in a standard T pose.
I change the property of the npc group member(inside my .czn_pc) from gang defensive to gang offensive.
This time, they followed my character....
by sliding with no animation from them (still this T pose).
Turn out they needed some .anim files.
I added the require file to my packages/asm...
The zombie now act as they should!

I'm surprised by this. So the buffer object is space we allocate for the cobjects. It is a fake filename and we just use this primitive to give us scratch memory. We just set it to num_objects * 4 bytes. If the buffer ends up NULL we won't call the load callback for the zone and if it doesn't exist as a prim we won't recognize the zone at all. A cobject is not a full-blown object, but instead something inside the zone that can't interact or be a target of script. Something like a building is a good example. Unique mesh with a 3d position, but you can't move it or delete it with script. (Technically this is a lie, we do hide cobjects in cutscenes at times, but it's just turning off rendering for them.)

Is there anything else outstanding here?

By cobject, do you mean the mesh_file_reference from the czh_pc files?

 

[[V] Knobby]

The zombie now act as they should!

That is great news!

By cobject, do you mean the mesh_file_reference from the czh_pc files?

No, I mean an internal...mini-object if you will. It was a construct from SR2 I believe and I think it stands for chunk object. SR2 called zones chunks and on RFG chunk meant something completely different so we decided to change the name to zone, but cobject stuck.