xboxscene.org forums

Pages: [1] 2 3 4

Author Topic: Readme - I Can, & Will, Make Custom Ini/offset  (Read 278 times)

dr.no

  • Archived User
  • Jr. Member
  • *
  • Posts: 64
Readme - I Can, & Will, Make Custom Ini/offset
« on: October 04, 2003, 12:18:00 AM »

Good idea imho. What about using .xml as a basis for those files?
Logged

xorange

  • Archived User
  • Newbie
  • *
  • Posts: 30
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #1 on: October 04, 2003, 12:42:00 AM »

QUOTE (dr.no @ Oct 4 2003, 09:18 AM)
Good idea imho. What about using .xml as a basis for those files?

The Cartographer file "mapkeys.ctg" looks like it's in XML format.
Any of the other files could be in XML too if the developers made their apps supprt the format.
I have a nice little XML editor that I'm using to work with Cartographer's PEP files, so I'm somewhat familiar with the format so far.
Logged

eXentric

  • Archived User
  • Jr. Member
  • *
  • Posts: 57
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #2 on: October 04, 2003, 12:46:00 AM »

Cartographer supports this, in theory. However, I chose to limit your choices when it comes to Class Type and Element Type. There is a reason for this.

Cartographer uses the Class Type and Element Types in an object model to look up the images and descriptions of each object. These entries are stored in resource tables. The Class Type isn't used too extensively right now, but the idea was to allow plugins to specify the class of object that they can modify and Cartographer would automatically filter plugins based on the item that was selected. This has never been implemented.

The item type, obviously, is a little more important to Cartographer. This is how we determine which  image (not fully implemented) and description to display on the screen.

Cartographer could be modified in three ways:

1. Someone gives me a list of every possible class ("Vehicle", "Projectile", etc) and every possible element ("Wounded Marine Sitting", etc) and I can allow those values to be used in the XML.

2. I allow you to put whatever you want in the Class and Element attributes. However, the item will loose any future plugin functionality and Cartographer will not be able to display an image or description for the item (except for, possibly, a supplied name) if Cartographer doesn't know the values you supply.

3. Make it so that even the elements images and text can be stored as part of the CTG file. This would require a lot of re-work and would loose multi-spoken-language support. I still haven't seen any interest expressed in the translation of Cartographer to another spoken lanuage, so this may be a mute point. (Solution #3 still does not address the plugin problem inherent to #2). Cartographer would be quite a bit larger with this soltion, because the images would be stored in base64 encoding (rather then in binary resources).

Any other suggestions are welcome. Solution #1 is obviously preferable, but I don't know if anyone wants to take the time (lord knows I didn't). Solution #2 would also work, with some limitations in future expansion. Solution #3 requires quite a re-working of the engine, but I could do it also. It does seem like the least beneficial option, however...
Logged

eXentric

  • Archived User
  • Jr. Member
  • *
  • Posts: 57
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #3 on: October 04, 2003, 01:39:00 AM »

Something else to think about:

I have already written a converter that sucks in output files in multiple directories and spits out a CTG file. That converter is what was used to generate the CTG files for Beta 5. The converter works for any output file regarless of region. That's why the PAL CTG file on the Cartographer website supports just as many items as the NTSC version.

The converter, however, simply ignores any Class types or Element types that it doesn't understand. That's why not everything is in there.

If someone were to take approach #1, it would be very beneficial because my converter could then understand every single item in the game and spit out a CTG file containing everything. In this case, class types would obviously become highly important because they would need to be used for filtering purposes.

I would have to add filtering into Cartographer if we go this route, but I had planned to do so at some point anyway...

The CTG file is XML. CTG was just made up as short for Cartographer, but I'm perfectly fine with calling it something else and making it a common format. If this was done correctly, the file really shouldn't change (because it would have everything). It could then be used by multiple applications.
Logged

xorange

  • Archived User
  • Newbie
  • *
  • Posts: 30
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #4 on: October 04, 2003, 08:41:00 AM »

QUOTE (eXentric @ Oct 4 2003, 09:46 AM)
Cartographer supports this, in theory. However, I chose to limit your choices when it comes to Class Type and Element Type. There is a reason for this.

Cartographer uses the Class Type and Element Types in an object model to look up the images and descriptions of each object. These entries are stored in resource tables. The Class Type isn't used too extensively right now, but the idea was to allow plugins to specify the class of object that they can modify and Cartographer would automatically filter plugins based on the item that was selected. This has never been implemented.

The item type, obviously, is a little more important to Cartographer. This is how we determine which  image (not fully implemented) and description to display on the screen.

Cartographer could be modified in three ways:

1. Someone gives me a list of every possible class ("Vehicle", "Projectile", etc) and every possible element ("Wounded Marine Sitting", etc) and I can allow those values to be used in the XML.

2. I allow you to put whatever you want in the Class and Element attributes. However, the item will loose any future plugin functionality and Cartographer will not be able to display an image or description for the item (except for, possibly, a supplied name) if Cartographer doesn't know the values you supply.

3. Make it so that even the elements images and text can be stored as part of the CTG file. This would require a lot of re-work and would loose multi-spoken-language support. I still haven't seen any interest expressed in the translation of Cartographer to another spoken lanuage, so this may be a mute point. (Solution #3 still does not address the plugin problem inherent to #2). Cartographer would be quite a bit larger with this soltion, because the images would be stored in base64 encoding (rather then in binary resources).

Any other suggestions are welcome. Solution #1 is obviously preferable, but I don't know if anyone wants to take the time (lord knows I didn't). Solution #2 would also work, with some limitations in future expansion. Solution #3 requires quite a re-working of the engine, but I could do it also. It does seem like the least beneficial option, however...

Hmm...I'm not entirely sure if I understand what you mean in the first part of this message, but I think I get the picture.
I think some of the terms we're using are being used differently in diff. contexts, thus confusing things a bit, but oh well...

I am interested in helping in any way with whichever method would be best for you & the further development of Cartographer.
Resolving #1 does sound like the way to go.
I'd very much like to discuss further what exactly you could use help with to acheive this functionality.


Here's an example of what I was trying to make Cartographer do for me (naive maybe, I don't know...I just experiment):

<element class="Equipment" type="RocketLauncherAmmo" offset="23442F8" value="4C659880" />
<element class="Equipment" type="ShotgunAmmo" offset="2342D78" value="A80B9280" />
<element class="Equipment" type="SniperRifleAmmo" offset="2344D58" value="34059B80" />
<element class="Model" type="characters/cyborg/cyborg" offset="233c918" value="649b7280" />
<element class="Model" type="characters/cyborg/fp/fp" offset="23488d8" value="2c8da980" />
<element class="Model" type="item collections/powerups/powerups" offset="2348158" value="5c1da980" />

You can see how I set the element type to show the path for Models.
I figured this would be the most effective because then you could take advantage of ordering elements by both class and path.
Very similar to the way the Element Editor is set up right now, just a bit different.
This would probably require a smaller font be used in the element editor.

Well, anyway...I like Cartographer a lot, I think the new release is great, I think it also has a lot more potential and I'd like to help if I can. happy.gif
Logged

Terminat0r

  • Archived User
  • Newbie
  • *
  • Posts: 25
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #5 on: October 04, 2003, 08:47:00 AM »

QUOTE
1. Someone gives me a list of every possible class ("Vehicle", "Projectile", etc) and every possible element ("Wounded Marine Sitting", etc) and I can allow those values to be used in the XML.


can you please be more specific

I think the beta 7 should have a filter and add Scenery. I will add the scenery to the ctg if thats ok?
Logged

CaicedoLuis

  • Archived User
  • Full Member
  • *
  • Posts: 129
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #6 on: October 04, 2003, 09:07:00 AM »

i would edit my proggy to allow ur format
Logged

eXentric

  • Archived User
  • Jr. Member
  • *
  • Posts: 57
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #7 on: October 04, 2003, 11:01:00 AM »

No diss taken, that is a nice feature.

I took a moment to take one of my source files and convert it to HTML. Although you may not know C#, hopefully you can get a little more of an idea what I'm talking about. Here's the link:

http://www.solersoft...ElementInfo.htm

If you'll notice, there is an enumeration for every supported class type and every supported element type. Further down in the file, you can see that I get two resource managers (one for strings and one for images). These resource managers are used to get the images and descriptions for every item.

Basically, if we really want this to work smootly, two things have to occur:

1. We would need to finish off the ElementClass enumeration and the ElementType enumeration (seen at the top of that page).

2. Someone would need to put descriptions in for each new element type. Images would be nice too, but I don't have images for everything in the system as it stands now. I was planning to work on that next...

Once those two things are done, a fairly small amount of work would need to be put into finishing the converter. But, I could easily do that and then we would have everything.

Any thoughts?
Logged

CaicedoLuis

  • Archived User
  • Full Member
  • *
  • Posts: 129
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #8 on: October 04, 2003, 11:04:00 AM »

i could make it generate a PPF. i did have the same prob it patched the first 3 or so cahces correctly and worked but then after that it didnt work i tried to fix that but couldnt find the problem
Logged

eXentric

  • Archived User
  • Jr. Member
  • *
  • Posts: 57
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #9 on: October 04, 2003, 11:14:00 AM »

In case that C# code didn't clear up everything, here are the two main parsing routines out of my output converter:

http://www.solersoft...verterParse.htm

Hope that clears it up. If not, let me know.
Logged

xorange

  • Archived User
  • Newbie
  • *
  • Posts: 30
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #10 on: October 04, 2003, 11:17:00 AM »

QUOTE (CaicedoLuis @ Oct 4 2003, 08:04 PM)
i could make it generate a PPF. i did have the same prob it patched the first 3 or so cahces correctly and worked but then after that it didnt work i tried to fix that but couldnt find the problem

That would be great if you could make MapPatcher generate PPFs!

I'm going to put up a page on my webhost this afternoon where I
can host the files I have created.
I'll send you a link asap.
Logged

CaicedoLuis

  • Archived User
  • Full Member
  • *
  • Posts: 129
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #11 on: October 04, 2003, 11:32:00 AM »

everyone post ur AIM/AOL so we can go into a chatroom and talk about a universal format

EDIT - Forgot to post my AIM!
CaicedoLuisA
Logged

xorange

  • Archived User
  • Newbie
  • *
  • Posts: 30
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #12 on: October 04, 2003, 11:55:00 AM »

QUOTE (CaicedoLuis @ Oct 4 2003, 08:32 PM)
everyone post ur AIM/AOL so we can go into a chatroom and talk about a universal format

EDIT - Forgot to post my AIM!
CaicedoLuisA

Hmm...message boards work best for me.
I'm on these boards, while I'm re-writing my resume, searching for a jobbyjob, hacking/playing Halo, trolling for pr0n on urdx.com, editing offset lists, auctioning/buying on Ebay and working on a PEP for Cartographer all at the same time.
If I tried to chat too I think either I'd explode or my stupid Athlon would start overheating.
happy.gif

Universal format...hmm...
Personally I like the format your hexranges.txt file is in because it's very easy to convert the entire ntsc_full_class files to it. (uh, PAL too I'm sure)
I like XML because it seems very functional and allows for a lot of customizing and expanding.
Logged

eXentric

  • Archived User
  • Jr. Member
  • *
  • Posts: 57
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #13 on: October 04, 2003, 01:12:00 PM »

QUOTE
Hmm....so, up at the top we'd need something like this


Thats correct. And anything else that's missing.

I'd prefer not to post my IM on a forum, although I'll give it to anyone that PMs me. I'm headed out to dinner right now. Perhaps we could hook up in an IRC channel if this is that urgent.

xorange, you are on the right track. Personally, I feel that XML is a good way to go (whether its the format I've already defined or a completely different one). It is very easy to read and very structured. You can easily represent hierarchies with it and objects can have attributes. To me as a programmer, it just makes sense (it's like a database in a portable file). Not to mention its SUPER easy to parse in .Net, although I understand not as easy to parse in other languages.

I'll check back later.
Logged

CaicedoLuis

  • Archived User
  • Full Member
  • *
  • Posts: 129
Readme - I Can, & Will, Make Custom Ini/offset
« Reply #14 on: October 04, 2003, 03:23:00 PM »

i like my format too and it would be a bitch to get my proggy to read XML (Stupid VB) unless eXentric would help
Logged
Pages: [1] 2 3 4