Does this mean people will now be able to mod saints row 3/4/gooh maps and all like could cribs and all be brought back to saints row 4 and what about stilwater.I know its a crazy question to ask but its just amazing to hear about it being possible to mod the map and imagine what modders can do with that along with bringing stilwater to saints row 3 and 4 and all.:)
 
Does this mean people will now be able to mod saints row 3/4/gooh maps and all like could cribs and all be brought back to saints row 4 and what about stilwater.I know its a crazy question to ask but its just amazing to hear about it being possible to mod the map and imagine what modders can do with that along with bringing stilwater to saints row 3 and 4 and all.:)
Unlikely, but you may be able to change the location of a nav point. That's almost as good, right? :D
 
you may be able to change the location of a nav point.

Would you please elaborate on the nav point properties and what is associated with them.:D

Thank you and keep up the good work. :cool:
 
Does it also make you cry?
When my software doesn't work the way I want it to, yes... I have been crying today! But now it's working so I'm better now. :)
Would you please elaborate on the nav point properties and what is associated with them.:D
Thank you and keep up the good work. :cool:
I wish I could be a little more specific about what, exactly, you'll be able to do with this tool, but I can't yet. I just know that Knobby was gracious enough to post the zone file format information here (2 years ago!), but I haven't seen any zone tools here yet, so I decided to take up the challenge. I'll provide the tools and then everyone can play around with them and see what they can do. I'm hoping this will open up some new possibilities. And, of course, I have ulterior motives, because there are some mods I've been wanting to make but I can't do them without editing the zone files. :cool:

And let me just add another thank you to Knobby. One thing that's kept me here on this forum is the fact that Volition is willing to provide such great support to us modders. I know they have limited resources and everyone is probably overworked and has a lot of other important things to do (Saints Row 5, perhaps :D), but I am really impressed that Knobby has taken the time to answer all of my questions and get me to the point where I can make sense out of the data in these zone files. It gives me incentive to keep working at this! Thanks again, Knobby!
 
Just wanted to give everyone a status update on my progress on this.
I have made significant progress on the ".czn_pc" <==> ".xml" file converter, and I am now able to convert ALL ".czn_pc" files in "sr3_city_0.vpp_pc" to XML format and back to identical ".czn_pc" files. I haven't tried tweaking any numbers yet, but I've attached a sample XML file generated by converting the file "sr3_city~fm06`.czn_pc" to XML format. This file can then be converted back to a ".czn_pc" file by simply running my program.

I had to do some crazy things so I could come out with identical files after conversion to pass my testing, including:
  1. A floating point value of "-0" (negative zero) is used in some of the quaternion orientation values, and that was REAL PAIN to convert to ASCII and back for the XML files. I suspect "0" and "-0" are functionally equivalent, but I had to use distinct values to pass testing. You'll see some of those in the XML file.
  2. The object property values are aligned on 4-byte boundries and contain padding at the end for odd length values, such as strings. The padding is NOT ALL ZEROS, so I had to save that padding as a separate field in the XML file. I suspect it's just garbage, but I had to retain it so testing would pass.
The format of the XML file is still in a state of flux, so expect changes.

I will get all of this up on GitHub (and here) as soon as I get a chance.
 

Attachments

  • sr3_city~fm06`.2015-07-16.7z
    24.9 KB · Views: 430
The object property values are aligned on 4-byte boundries and contain padding at the end for odd length values, such as strings. The padding is NOT ALL ZEROS, so I had to save that padding as a separate field in the XML file. I suspect it's just garbage, but I had to retain it so testing would pass.
I'd suggest checking if it is garbage or not - if it is then just throw it away. Matching byte for byte isn't important, but you don't want to have to specify useless padding when making changes.
 
Back
Top