Did you use my zone file tools to do this?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!
Did you use my zone file tools to do this?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!
Of courseDid you use my zone file tools to do this?
That's fantastic! I'm glad to finally see someone getting some use out of it. Great job!Of course
<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>
I'm unsure if you're allowed to reuse the same handle value. Knobby could probably give you advice on that.
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...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.
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)As always, send zips if you want us to look at something.
Don't worry, I'm not heavily working on this.Sorry I didn't have a chance to get back to you sooner.
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]
...
Ability to add/remove/move/change furniture!?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.
Yes. (no change)Did you try the things I mentioned in my last post?
It is simply a duplicate/rename of dlc1_3c zone, but I will attach the files.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!
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.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".
We can understand that adding extra data cause the "offset" to be no more valid...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] ...
but fixing the offset value is not enough.(even if the 0x2250 section is removed)
= game still bugged.
Move it, YES, at the very least, and hopefully add/remove/change it. I've already removed doors from buildings using this technique.Ability to add/remove/move/change furniture!?
Okay. Thanks. Hmmmmm. I'll try to play around with it a little after I finish releasing my updated zone tool.Yes. (no change)
Thanks.It is simply a duplicate/rename of dlc1_3c zone, but I will attach the files.
Knobby would be much more knowledgeable in that area, so I will defer those questions to him.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"?