Saints Row IV Is it hard-coded directly to the game exe?

Look like I still need help :(
Should I said that my ~al.czn_pc didn't contain any "Object Section Data" (0x2234 )?
This can explain why thing went so "smooth".
However, I can't say the same about inserting data to a file that already contain "Object Section Data".
To be more specific the normal lod .czn_pc of my zone.
Tried with the "zombie group":
Game keep crashing no matter what.
Btw, I removed the group from the ~al.czn_pc to prevent conflict/fake result.
Tried with a simple navpoint...
Game is bugged when entering the zone:
Character is stuck, weapon icon show grey square instead of the correct icon, lot of object from the zone are missing, car/npc dissapear when entering the zone, etc.
Remember that my first attempt about modding the .grid_pc was giving similar bug = I was doing script error.
So we can be pretty sure that this time, I'm doing something wrong in my .czn_pc file.

I simply inserted this navpoint data and add its handle value to the handle list...
The object index value do not matter since the app resort the number base on the object order.
Code:
<object index="494">
              <!-- navpoint -->
              <name>nav_chase_001</name>
              <handle>0x04BD82DC04EA0067</handle>
              <parent_handle>0x0000000000000000</parent_handle>
              <object_type_hash>0x445C1F3D</object_type_hash>
              <padding>0</padding>
              <properties>
                <property index="1">
                  <!-- compressed transform -->
                  <type>2</type>
                  <name_crc>0xC8BEEEC5</name_crc>
                  <value>
                    <position>
                      <x>1188.89453125</x>
                      <y>24.7188949584961</y>
                      <z>1370.55285644531</z>
                    </position>
                  </value>
                </property>
                <property index="2">
                  <!-- string -->
                  <type>0</type>
                  <name_crc>0x355EF946</name_crc>
                  <value>
                    <string>nav_chase_001</string>
                  </value>
                  <padding>
                    <rawdata format="hex">00 00</rawdata>
                  </padding>
                </property>
                <property index="3">
                  <!-- string -->
                  <type>0</type>
                  <name_crc>0xB7A1B604</name_crc>
                  <value>
                    <string>Floating</string>
                  </value>
                  <padding>
                    <rawdata format="hex">72 65 65</rawdata>
                  </padding>
                </property>
              </properties>
            </object>
But the game just keep bugging.
I increased the value of my asm buffer...
but like I was expecting this did nothing.
Knobby explained the buffer usage in his previous post, so it was already clear to me that the buffer wasn't related to the object section data.
I'm missing something, but I can't figure out what.
 
Make sure, when you insert a new object, ONLY insert it at the end of the list and the new handle at the end of the handle list.

Also, make sure you read the section "Things You Shouldn't Do" in the "SRZoneTool.html" file. That's very important.

Don't use the "--rebuild-handle-list" option, if you're using it.

I'm unsure if you're allowed to reuse the same handle value. Knobby could probably give you advice on that.

UPDATE: If there's anything I can do to help you out, let me know. I will be unavailable tomorrow until early next week, but if you want to send me some files or XML, I'd be happy to do whatever I can.
 
Last edited:
I'm unsure if you're allowed to reuse the same handle value. Knobby could probably give you advice on that.

Handle values are required to be unique across the entire game. We typically handed out a block of handles per-user and when they exhausted that block we would give them another one. I'm sure there are tons of free handles, but it might be somewhat difficult to find them. Guessing might just work here. :) I'm not sure what the game would do if you used the same handle as something else, my guess would be that your object would fail to create.

As always, send zips if you want us to look at something.
 
Handle values are required to be unique across the entire game. We typically handed out a block of handles per-user and when they exhausted that block we would give them another one. I'm sure there are tons of free handles, but it might be somewhat difficult to find them. Guessing might just work here. :) I'm not sure what the game would do if you used the same handle as something else, my guess would be that your object would fail to create.
I don't know if it's what you meant to say, but I think that as long we dont' have multiple currently loaded object asking for the same handle at the same time...
we're fine.
For exemple, all the handle used by the mission will be valid to use for our "custom zone" as long we don't enter these given mission.
Should I said that when I added the "zombie" from the mol_mm mission .czn_pc to my zone swap .czn_pc, I didn't change any of the handle value?
One curious thing however, thing appear to work even if the handle used by your object are different from the one inside the handle list.
When I added object to my ~al.czn_pc, I had 8 handle in my file: 4 in the object list and 4 in the object property...
and the zombie still worked as expected. o_O

UPDATE: Forget to mention that object from ~al.czn_pc will be available in all zone.
Meaning that the id of their handle should be avoided.
However, object from normal lod .czn_pc will only be create if we're inside the given zone...
and dissapear when we enter another zone.(I guest it the same for high lod)
This mean that their id should be valid for our "custom zone".(we can't be in multiple zone at the same time)

As always, send zips if you want us to look at something.
The vpp contain a gameplay lua for turning on the zone swap and looping a prompt (press E) to teleport directly in front of the 3 count casiono. (directly in the zone)
The rest of the file are required file for a working zone.
Like I said, my ~al.czn_pc have been put back to normal (no more zombie)
The file that I'm trying to mod right now is "sr3_city~f1608^k4n3_3c.czn_pc" from "1608^k4n3_3c.str2_pc".
I simply added a nav point(see my previous post) to it.
There is also a copy of the file converted to .xml (thank to Quantum app) inside the zip.
I really hope you can find out why I can't get this to work.

UPDATE: I managed to narrow down the source of the issue.
If I remove the section 11 and 13...
the bug is gone!(both must be removed)
Section 4 = 0x2234 - objects - nav points, environmental effects, and many, many more things
Section 11 = 0x2247 - water volumes
Section 13 = 0x2250 - parking data
 

Attachments

  • k4n3 zone bug test.zip
    34.4 MB · Views: 355
Last edited:
Sorry I didn't have a chance to get back to you sooner.

I'm about to release a major new version of my SRZoneTool program which will parse much of the Crunched Reference Geometry section, allowing you to easily move "fast" objects around on the map. I'm hoping you'll be able to add and remove objects too, but we'll see.

Did you try the things I mentioned in my last post?

Could you send the XML files before and after your change so I can compare them and see exactly what you changed? That would help a lot, because I can't find the original files you started with. Thanks!
 
Sorry I didn't have a chance to get back to you sooner.
Don't worry, I'm not heavily working on this.

I should mention that this is only a test and not an actual mod in progress.
Of course, we do need to understand how to fix it. (so we can repeat on other zone mod work)
I pointed out the cause of the issue in my last post. (in the last update)
For some reason, adding object to the 0x2234 section will screw up the 0x2247 and 0x2250 sections.
I noticed that the "0x2247 - water volumes" is made of multiple "subsection".
Code:
0x80002247
---
Signature(32bit) = [47 22 00 80]
Size of section(32bit)
???(32bit) = [00 00 00 00]
num of subsection(32bit)
FOR EACH SUBSECTION {
    start offset of the subsection(32bit)
}
???(32bit) = [00 00 00 00]
...
We can understand that adding extra data cause the "offset" to be no more valid...
but fixing the offset value is not enough.(even if the 0x2250 section is removed)
= game still bugged.

I'm about to release a major new version of my SRZoneTool program which will parse much of the Crunched Reference Geometry section, allowing you to easily move "fast" objects around on the map. I'm hoping you'll be able to add and remove objects too, but we'll see.
Ability to add/remove/move/change furniture!?

Did you try the things I mentioned in my last post?
Yes. (no change)

Could you send the XML files before and after your change so I can compare them and see exactly what you changed? That would help a lot, because I can't find the original files you started with. Thanks!
It is simply a duplicate/rename of dlc1_3c zone, but I will attach the files.

NEW QUESTIONS:
I want to add some spawn region object to my zone file...
but their is two of their property that I need to understand.
crc = 0x2170608B and 0x1D7D5FD2.
Both seem to use 12 bytes of data (must mean 3 value of 4 bytes)
What are these suppose to be?

How do interior zone are triggered?
I copied/renamed the wh_end^wh zone files(like I did with dlc1_3c) and tried to add it as a zone swap of the wh_end zone...
but the game don't trigger it.
I guest interior zone have some "extra rules"?
 

Attachments

  • k4n3 czn_pc xml comparaison.zip
    219.6 KB · Views: 300
Don't worry, I'm not heavily working on this.

I should mention that this is only a test and not an actual mod in progress.
Of course, we do need to understand how to fix it. (so we can repeat on other zone mod work)
I pointed out the cause of the issue in my last post. (in the last update)
For some reason, adding object to the 0x2234 section will screw up the 0x2247 and 0x2250 sections.
I noticed that the "0x2247 - water volumes" is made of multiple "subsection".
Code:
0x80002247
---
Signature(32bit) = [47 22 00 80]
Size of section(32bit)
???(32bit) = [00 00 00 00]
num of subsection(32bit)
FOR EACH SUBSECTION {
    start offset of the subsection(32bit)
}
???(32bit) = [00 00 00 00]
...
We can understand that adding extra data cause the "offset" to be no more valid...
but fixing the offset value is not enough.(even if the 0x2250 section is removed)
= game still bugged.
Are the offsets from the beginning of the Section or the beginning of the File? If they're from the beginning of the Section, then removing the section shouldn't cause problems due to offsets, however other parts of the code (or zone file) may expect that section to exist, and may crash and burn if it doesn't exist.

EDIT 2017-05-08: After looking through the file I see what you mean -- the offsets are from the beginning of the zone file, which will cause a lot of problems when you try to add or remove something. I can add that section to my SRZoneTool so it will automatically fix up those offsets, however I'll also have to figure out how to fix the other section that's causing problems. Have you figured out how to parse that?
Ability to add/remove/move/change furniture!?
Move it, YES, at the very least, and hopefully add/remove/change it. I've already removed doors from buildings using this technique.
The trick with adding/removing things is that there are sometimes offsets into the file that need to be fixed up in those cases, as you have already discovered. And if I don't know how to parse those sections, I can't fix them up. But you CAN always remove things by moving them under the map, which is what I did.

But I'll be releasing the updated tool soon, and if you want to play around with it, I'd appreciate any feedback about issues or improvements I can make.
Yes. (no change)
Okay. Thanks. Hmmmmm. I'll try to play around with it a little after I finish releasing my updated zone tool.
It is simply a duplicate/rename of dlc1_3c zone, but I will attach the files.
Thanks.
NEW QUESTIONS:
I want to add some spawn region object to my zone file...
but their is two of their property that I need to understand.
crc = 0x2170608B and 0x1D7D5FD2.
Both seem to use 12 bytes of data (must mean 3 value of 4 bytes)
What are these suppose to be?

How do interior zone are triggered?
I copied/renamed the wh_end^wh zone files(like I did with dlc1_3c) and tried to add it as a zone swap of the wh_end zone...
but the game don't trigger it.
I guest interior zone have some "extra rules"?
Knobby would be much more knowledgeable in that area, so I will defer those questions to him.

Unfortunately, I still don't have enough information to parse all the object property formats in the zone file, so that's why those properties are just strings of hex bytes. And I don't have a dictionary to decode many of the CRCs into text names. :(
I have added all the object type names, thanks to Minimaul, and they're in my latest release 2.5 of the zone file tools which I released on Tuesday.

But if Knobby or you can figure out how to parse some of those fields you mentioned (or others), I'd be happy to add them to my zone tools.
 
Last edited:
Back
Top