First off, this is my first post, but I've been on this site for a while and HaloMods pWnz! All of you responsible for such things like HMT, Sparkedit, and he tutorials can never be repaid! I can actually wait a lifetime for Halo 2 now... Anyways, now that that's out of the way...
I would like to know how, if it is possible, I can have multiple types of Warthogs in a map.
For instance, if I wanted to make one warthog that doesn't have the turret and one that does.
Thank you all for your undying efforts!
Multiple Types of Warthogs in One Map
Multiple Types of Warthogs in One Map
HaloMods.com is like Fight Club...think about it.
I was looking into that whits morning with the add new tag into scenery with se3. It seems as though there are no new tags to add this into the scene with, but I may be wrong. Unless you do some editing in the right places for map callout, not sure if this is possible. Would be nice to get some more input on this topic, because it could add a whole new dimension to xbox maps.
__Blaz0__
__Blaz0__
You would more or less have to rebuild the map with a duplicated warthog, (but editing the warthog to point to different files from the original warthog). The function in Sparkedit is to add new tags to the scenario which basically means that instead of swapping the new vehicle with, say a ghost, you can have all of the vehicles in there.
Well Iron forge says is is possible use hex editing to clone a warthog and have two however his site is down or something. He had a tutorial on the theory of how to do it.
So if you got that tut and used this link that shows how Cluis did it.
And you have the right pugins for HMT. I think it is possible
http://www.halomods.com/forums/viewtopi ... turret+tut
Good luck
So if you got that tut and used this link that shows how Cluis did it.
And you have the right pugins for HMT. I think it is possible
http://www.halomods.com/forums/viewtopi ... turret+tut
Good luck
Iron_Forges Tuts mentioned earlier
Sorry About the large post
hopefully by now you are a master at meta modification. No? Well, don't feel bad, most people seem to have difficulty grasping meta. But take my word for it, once you take the time to learn it, you will question how you never realized just how easy it is.
You should realize by now that meta is composed of reflexive offsets, reference offsets, meta data itself, and padding. I find the best way to understand meta is to think of it in a way that you can relate to. This is difficult for me to explain, because I relate to things through coding, which for most people is more complex than meta.
As such, we are going to look at meta from the perspective of the warthog. The warthog itself, is a vehicle, and it has a vehicle meta object. If you look at this object, there is acctually very little true meta data in it. It starts out as being around 4000 bytes, but if you ignore all the references (those are the things which point to other objects remember), and the reflexives (offsets which point to more meta), theres not many values left. Many of whats left are just 0's, and 0's are usually just padding, extra data, things you can ignore. ;o)
Now to throw you a nice loop, the warthog vehicle has no texture. Thats right, theres no bitmap, no tga, nothing that makes it look like the warthog you see. Confused? Well, you have to remember all those references. The warthog vehicle, if you look at its meta, is made up of lots of references to other files. In its meta, there is not a single bitm (mtib) reference. How can this be you ask? Well, near the beginning of it, there *is* a model reference. This tells the warthog vehicle to use that model.
The model has references to shaders, and shaders have references to bitmaps. Building an object in Halo is like building with toy lego blocks. The vehicles are big creative toys you can use, but if you smash them with a hammer, they become model, physics, collision, and a number of effects. If you take each of those, and smash them apart, they become even smaller pieces, until you reach an object which is made up on its own, such as a texture or bitmap. If you look at a bitmaps meta, its only 220 bytes! Thats very small, but its not made up of anything, thats just descriptive data (and some reflexive offsets in to confuse you.)
This 'true' descriptive data describes a number of things, from the size of the texture, its width, height, the number of colors it may have, the format its stored, etc. This is the true meta. Even the vehicle has true meta. It has values to tell it how to put everything together, and how each of its parts should work together. These are the things like its speed, how fast it gets to that speed, how well it can stop, how it handles your controlling of it, etc.
References in meta are *so* easy to spot, because they always start with the tag. You can think of these as even better offset swap spots. If you look at a weapons meta for instance, it will have a reference to the projectile it shoots (as well as meta describing how many of these projectiles it should shoot a second.) So if you want your assault rifle to shoot rockets, you could go to the assualt rifle meta, and find its projectile reference, and change it. The reference is always made up of the starting tag, the file offset of the referenced object, a 0, and then the identifier of the referenced object. Its good to change the file offset and identifier, but the game engine only needs the identifier changed (editors are what need both.)
By changing references to offset swap, instead of the original offset swap method, you can narrow down your effected objects. If two weapons for instance use the assault rifle bullet, and you offset swap that with rockets, both will now fire rockets. If you edit the projectile reference in the assualt rifles meta, you can leave the other weapon un-effected.
Another related Iron Forge TUT
Now that you see that meta is relatively small once you pickout all the references, its time to learn something which is growing more popular. Meta duplication, is just what it sounds like. Taking the meta from one object, and creating another object with that meta.
What good is this you ask? Well, recently I duplicated the banshee, creating a second banshee, which had its own model, textures, and weapons. The same could be done for weapons, creating two similar, but distinct weapons.
When you take the meta from one object and copy it, you do need somewhere to put it, so find an object which isn't in use, or won't be missed. Scenery is common, who's going to miss a bush or tree? The meta for the object your duplicating has to be smaller than the meta your replacing (more on this later.) This is common sense, you can't fit a big banshee into a little box now can you? Now that you've selected all your meta, and copied it over, it will work fine, you've just duplicated. But wait, theres a problem.
Reflexive offsets are those offsets which point to somewhere further in the meta your editing. But you just duplicated your meta to a new location, and all those reflexives still point to the original object. What you need to do is find all the reflexive offsets in the meta your copying, its usually a simple time consuming tasks, as reflexives usually end in 40 or 41 (80 or 81 for xBox maps), same as all the other offsets people are (hopefully) familiar with using.
So you will have to take their value (easily obtained from your data inspector in Hex Workshop saving you the headaches of little/big endian conversion), subtract pesky magic, and then go to that offset. It (should) take you somewhere into the original object, usually near a reference tag. Make a mental note of where this is, and return to your duplicated meta. Once there, try to find the location that you just pointed to in the original meta, and get its offset. To this you will add magic, and then change that reflexive offset to this point.
That needs to be done for all of the reflexives, so that they now point to the correct locations in your newly duplicated meta instead of their old meta points. Once this is done, you've completely duplicated meta. All of the references can remain the same of course, since they do not depend on where the meta is to begin with.
This brings up a new topic, which is slightly more complex, meta shaving. I hope with your new found understanding of reflexives and references, you now see how they interact. Reflexives usually point to something of importance, either 'true' meta data, or a list of references. Lets say for instance, your duplicating a projectile, and want to give it homing, or faster speeds, or any number of changes. However, you wish all of its effects to stay the same. The effect of the projectile hitting grass or dirt won't change for this type of mod. So begin looking for the first reflexive which points to an area after the value you are changing. Once you found this, if you change this reflexive back (or don't bother changing it in the first place), it will now share its meta with the original object.
This is a hard theory to grasp, but try and think of that reflexive as 'true' meta, describing where something that projectile needs is located. Since that data is the same for both objects, they can share this location. Now that your new meta points to the original for that block of data, you no longer need to copy it. By 'shaving' the meta this way, you can greatly decrease the size of what your copying, giving you a greater choice of places to replace with it. This can of course only be used for portions *after* the area your modifying, and at the end of the meta. You cannot remove from that point on if other reflexives point into that area, unless you also leave them to point to the original (and will use the originals data aswell.)
Sorry About the large post
hopefully by now you are a master at meta modification. No? Well, don't feel bad, most people seem to have difficulty grasping meta. But take my word for it, once you take the time to learn it, you will question how you never realized just how easy it is.
You should realize by now that meta is composed of reflexive offsets, reference offsets, meta data itself, and padding. I find the best way to understand meta is to think of it in a way that you can relate to. This is difficult for me to explain, because I relate to things through coding, which for most people is more complex than meta.
As such, we are going to look at meta from the perspective of the warthog. The warthog itself, is a vehicle, and it has a vehicle meta object. If you look at this object, there is acctually very little true meta data in it. It starts out as being around 4000 bytes, but if you ignore all the references (those are the things which point to other objects remember), and the reflexives (offsets which point to more meta), theres not many values left. Many of whats left are just 0's, and 0's are usually just padding, extra data, things you can ignore. ;o)
Now to throw you a nice loop, the warthog vehicle has no texture. Thats right, theres no bitmap, no tga, nothing that makes it look like the warthog you see. Confused? Well, you have to remember all those references. The warthog vehicle, if you look at its meta, is made up of lots of references to other files. In its meta, there is not a single bitm (mtib) reference. How can this be you ask? Well, near the beginning of it, there *is* a model reference. This tells the warthog vehicle to use that model.
The model has references to shaders, and shaders have references to bitmaps. Building an object in Halo is like building with toy lego blocks. The vehicles are big creative toys you can use, but if you smash them with a hammer, they become model, physics, collision, and a number of effects. If you take each of those, and smash them apart, they become even smaller pieces, until you reach an object which is made up on its own, such as a texture or bitmap. If you look at a bitmaps meta, its only 220 bytes! Thats very small, but its not made up of anything, thats just descriptive data (and some reflexive offsets in to confuse you.)
This 'true' descriptive data describes a number of things, from the size of the texture, its width, height, the number of colors it may have, the format its stored, etc. This is the true meta. Even the vehicle has true meta. It has values to tell it how to put everything together, and how each of its parts should work together. These are the things like its speed, how fast it gets to that speed, how well it can stop, how it handles your controlling of it, etc.
References in meta are *so* easy to spot, because they always start with the tag. You can think of these as even better offset swap spots. If you look at a weapons meta for instance, it will have a reference to the projectile it shoots (as well as meta describing how many of these projectiles it should shoot a second.) So if you want your assault rifle to shoot rockets, you could go to the assualt rifle meta, and find its projectile reference, and change it. The reference is always made up of the starting tag, the file offset of the referenced object, a 0, and then the identifier of the referenced object. Its good to change the file offset and identifier, but the game engine only needs the identifier changed (editors are what need both.)
By changing references to offset swap, instead of the original offset swap method, you can narrow down your effected objects. If two weapons for instance use the assault rifle bullet, and you offset swap that with rockets, both will now fire rockets. If you edit the projectile reference in the assualt rifles meta, you can leave the other weapon un-effected.
Another related Iron Forge TUT
Now that you see that meta is relatively small once you pickout all the references, its time to learn something which is growing more popular. Meta duplication, is just what it sounds like. Taking the meta from one object, and creating another object with that meta.
What good is this you ask? Well, recently I duplicated the banshee, creating a second banshee, which had its own model, textures, and weapons. The same could be done for weapons, creating two similar, but distinct weapons.
When you take the meta from one object and copy it, you do need somewhere to put it, so find an object which isn't in use, or won't be missed. Scenery is common, who's going to miss a bush or tree? The meta for the object your duplicating has to be smaller than the meta your replacing (more on this later.) This is common sense, you can't fit a big banshee into a little box now can you? Now that you've selected all your meta, and copied it over, it will work fine, you've just duplicated. But wait, theres a problem.
Reflexive offsets are those offsets which point to somewhere further in the meta your editing. But you just duplicated your meta to a new location, and all those reflexives still point to the original object. What you need to do is find all the reflexive offsets in the meta your copying, its usually a simple time consuming tasks, as reflexives usually end in 40 or 41 (80 or 81 for xBox maps), same as all the other offsets people are (hopefully) familiar with using.
So you will have to take their value (easily obtained from your data inspector in Hex Workshop saving you the headaches of little/big endian conversion), subtract pesky magic, and then go to that offset. It (should) take you somewhere into the original object, usually near a reference tag. Make a mental note of where this is, and return to your duplicated meta. Once there, try to find the location that you just pointed to in the original meta, and get its offset. To this you will add magic, and then change that reflexive offset to this point.
That needs to be done for all of the reflexives, so that they now point to the correct locations in your newly duplicated meta instead of their old meta points. Once this is done, you've completely duplicated meta. All of the references can remain the same of course, since they do not depend on where the meta is to begin with.
This brings up a new topic, which is slightly more complex, meta shaving. I hope with your new found understanding of reflexives and references, you now see how they interact. Reflexives usually point to something of importance, either 'true' meta data, or a list of references. Lets say for instance, your duplicating a projectile, and want to give it homing, or faster speeds, or any number of changes. However, you wish all of its effects to stay the same. The effect of the projectile hitting grass or dirt won't change for this type of mod. So begin looking for the first reflexive which points to an area after the value you are changing. Once you found this, if you change this reflexive back (or don't bother changing it in the first place), it will now share its meta with the original object.
This is a hard theory to grasp, but try and think of that reflexive as 'true' meta, describing where something that projectile needs is located. Since that data is the same for both objects, they can share this location. Now that your new meta points to the original for that block of data, you no longer need to copy it. By 'shaving' the meta this way, you can greatly decrease the size of what your copying, giving you a greater choice of places to replace with it. This can of course only be used for portions *after* the area your modifying, and at the end of the meta. You cannot remove from that point on if other reflexives point into that area, unless you also leave them to point to the original (and will use the originals data aswell.)