Well yesterday I spent about 4 hours reading up on how to design plguins. I finally figured it out, and it is all thanks to xbox7887 and his tutorials.
The tutorial that helped me: http://files.halomods.com/viewtopic.php ... g+tutorial
If any of you would like a plugin made, tell me, and I will get right to work on it. Just tell me what tag it is for. Leave me some feedback on my first plugin
Nice work man. Its good to see that some people are willing to take the time to learn how to do that. I wish I had that kind of time to do stuff like this, aahhh stupid school.
ezekiel72 wrote:so with this im pretty sure u can make any object lighter including weapons so lets say we can make weapons fly farther like they did in halo 1?
Well not really, weapons arent in the blox tag. This plugin only applys to those. It also doesnt effect the rate at which things fall, although I am sure there is a value for it.
*searches*
Why doesn't anyone work with IFPs? They're already mapped, all you have to do (usually) is rename from "Unknown" to the name you want.
If it's because it's too hard to find the right unknown to rename in the .ifp, I can make a program to aid and make this much easier. I'd really like to see people mapping IFPs more.
Also, if you dislike Insolence's tag editing interface (I think Insolence is all that supports IFPs now), let me know and I'll make a small quick editing program designed how you like. Draw a mock-up in MS Paint or something.
If nobody uses these because few programs support them, encourage the authors to add IFP support. It's not difficult. For me it was easier to implement IFP than XML.
I'm not certain everyone understands the difference between these standard "plugin" style things you're making and an IFP, but there's a great difference which will make a huge difference as more and more values get mapped also.
Picture this:
XML plugin systems, Ch2r's, DarkMatter's, Insolence's XML, etc, all of these non-IFP plugin systems have a format similar to what follows:
"The value for jump height is at location 0x30 and is a float."
"The value for crough time is at location 0x2C and is a short.", etc.
(just examples, these aren't correct.)
So picture this giant block of data, most of it unknown, and instead of having some sort of structure layout, you have a set of labeled pointers in random order. It doesn't much help map a tag since you can't tell what's next to what, what kinds of values are around a given label, etc.
In an IFP, the entire tag is mapped out, but labeled as unknown. For example, starting at the beginning of a tag, an IFP tells the program something like:
"Unknown Int, Unknown Short, unknown Short, Jump height Float, Unknown Float, Crouch Time Short, Unknown int, Unknown int".
So the entire block of data is mapped, but most is labeled unknown. A major advantage of this is that you can see "Hmm, there's an unknown float inbetween Jump Height and Crouch Time" or something similar, and for those of you with Geurilla, you can open a bipd tag, find jump height, crough time, and look for some other value that would be a float inbetween or near them. Also, from a programming stand point, as a programmer, I thought it was easier to implement IFPs than XML plugins. IFPs you just read the tag exactly how the IFP says. Start at the beginning, read the IFP, if it says int, read an int, if it says float, read a float, continue until the end of the IFP.
The whole point of IFPs was to provide an easy-to-modify layout to make it so that it'd be easier/faster to map every tag. IFP's already exist for every tag, bloc included, why not use them instead of redoing work someone else has already done for you?
tjc2k4 wrote:Why doesn't anyone work with IFPs? They're already mapped, all you have to do (usually) is rename from "Unknown" to the name you want.
If it's because it's too hard to find the right unknown to rename in the .ifp, I can make a program to aid and make this much easier. I'd really like to see people mapping IFPs more.
Also, if you dislike Insolence's tag editing interface (I think Insolence is all that supports IFPs now), let me know and I'll make a small quick editing program designed how you like. Draw a mock-up in MS Paint or something.
If nobody uses these because few programs support them, encourage the authors to add IFP support. It's not difficult. For me it was easier to implement IFP than XML.
I'm not certain everyone understands the difference between these standard "plugin" style things you're making and an IFP, but there's a great difference which will make a huge difference as more and more values get mapped also.
Picture this:
XML plugin systems, Ch2r's, DarkMatter's, Insolence's XML, etc, all of these non-IFP plugin systems have a format similar to what follows:
"The value for jump height is at location 0x30 and is a float."
"The value for crough time is at location 0x2C and is a short.", etc.
(just examples, these aren't correct.)
So picture this giant block of data, most of it unknown, and instead of having some sort of structure layout, you have a set of labeled pointers in random order. It doesn't much help map a tag since you can't tell what's next to what, what kinds of values are around a given label, etc.
In an IFP, the entire tag is mapped out, but labeled as unknown. For example, starting at the beginning of a tag, an IFP tells the program something like:
"Unknown Int, Unknown Short, unknown Short, Jump height Float, Unknown Float, Crouch Time Short, Unknown int, Unknown int".
So the entire block of data is mapped, but most is labeled unknown. A major advantage of this is that you can see "Hmm, there's an unknown float inbetween Jump Height and Crouch Time" or something similar, and for those of you with Geurilla, you can open a bipd tag, find jump height, crough time, and look for some other value that would be a float inbetween or near them. Also, from a programming stand point, as a programmer, I thought it was easier to implement IFPs than XML plugins. IFPs you just read the tag exactly how the IFP says. Start at the beginning, read the IFP, if it says int, read an int, if it says float, read a float, continue until the end of the IFP.
The whole point of IFPs was to provide an easy-to-modify layout to make it so that it'd be easier/faster to map every tag. IFP's already exist for every tag, bloc included, why not use them instead of redoing work someone else has already done for you?
I would very much appreciate the program to help in labeling unknowns, if you have time to create it.
xbox7887 wrote:IFPs are obsolite, if they would support more data types it would be much better
Obsolete? More data types? How is a file which describes the entire layout of a tag obsolete compared to a plugin file which labels random stabs at the data?
They support more data types than DarkMatter's plugin system... Which data types are missing? None that I know of, but if any were overlooked, please let me know.