HEADS UP - Menu-Ini editor (WIP) [Archive]

View Full Version : HEADS UP - Menu-Ini editor (WIP)

vanjast

12-25-13, 04:35 PM

After many years decided to attack this :arrgh!:
A week into this so far.. and making good progress.

Any ideas from you lot ?
I have ideas what I want to do.. but added input is always welcome!

I have an idea where this will go eventually..
- provide a graphical interface/editor for SH3/4.. maybe SH5
- replace S3D in it's entirety
- replace code modules (far into the future, if at all!! - will assess this)

Naturally this all depends on my free time... but anyway.. I'll be back in the new year with progress..
:D

areo16

12-25-13, 09:13 PM

radcapricorn

12-26-13, 04:34 AM

:o I uh... Well... Damn it. That just goes to show one has to announce one's work! vanjast, I've been recently working on menu editor myself. Made a good progress too, main loading/presentation facilities are laid out, no material loader just yet but it's coming along.

http://img594.imageshack.us/img594/2074/kbq1.png (http://imageshack.us/photo/my-images/594/kbq1.png/)

This is how it looks right now. Not much to look at, but it's a basis.

So... Maybe we could collaborate on this? What do you say?

EDIT: I was going to announce this too, eventually, especially since I knew I'd need insight from people experienced with editing menu.ini. Hardcoded IDs, item behavior under various settings, parameters that I don't fully understand, that sort of thing. I also wanted to include things like dials.cfg, commands.cfg and menu_{en,de}.txt editing, to be more or less feature complete.

vanjast

12-26-13, 02:10 PM

We can do...

I'm only a week into this so it still looks like a skeleton.
These are my ideas so far.

- The left Treeview (TV) extracts the menu file as it is.. character-for-character, and when saved written back to the ini file as is. A track of backup files is generated.

- Selecting an item in the left TV, places that item and all it's details into the right TV... depending what it contains, is displayed in the image section to the right.

- The right TV can display Parent/Child relationships, and the whole selected menu page structure. an image file interface (as seen in game) appears on the right. Here you can graphically select, resize and move.. all updates are automatic to the right TV parameters.

- Other features will be ID checking, renumbering, insertion, links to other files (images and otherwise).. auto udating, backups... whatever come to mind :D
Generally the idea is to make the INI file stable

So in a sense we would have an interface editor for the mods to play with.

http://img.photobucket.com/albums/v297/vanjast/MenuEdt2_zps14c1e9ae.jpg (http://smg.photobucket.com/user/vanjast/media/MenuEdt2_zps14c1e9ae.jpg.html)
https://www.dropbox.com/s/qm4ndu6tb29eha9/MenuEdt2.jpg

Madox58

12-26-13, 02:20 PM

Very cool work Guys.
:up:

What are you programming in? C#?
If I can assist with any questions feel free to PM me.
I kind of know my way around the files.
:03:

vanjast

12-26-13, 03:11 PM

Thanks privateer..
I'll pm a few questions later with regard to some of the parameters...

oh.. The dev kit is Masm32.
:up:

Madox58

12-26-13, 03:28 PM

Wow! Impressive! I dropped assembly years ago for C and C++
:salute:

radcapricorn

12-26-13, 03:45 PM

We can do...

Fantastic!

I'm only a week into this so it still looks like a skeleton.
These are my ideas so far.

- The left Treeview (TV) extracts the menu file as it is.. character-for-character, and when saved written back to the ini file as is.

:hmmm: Is that prudent? I mean, AFAICT the ini structure itself with those [Gxx Iyyy] identifiers just represents the actual UI tree (or forest, actually), but flattened backwards. These bracketed numbers don't present any meaningful info for editing, do they? Plus if you store them, you'd have to recalculate them for the whole subtree every time you add or remove UI elements, instead of just once when saving the file.

IDs (ItemID, ParentID), on the other hand, are a different matter, since they are pretty much responsible for the actual UI structure.

A track of backup files is generated.

Backups are certainly a must. But what do you mean by "track"?

- Selecting an item in the left TV, places that item and all it's details into the right TV... depending what it contains, is displayed in the image section to the right.

- The right TV can display Parent/Child relationships, and the whole selected menu page structure. an image file interface (as seen in game) appears on the right. Here you can graphically select, resize and move.. all updates are automatic to the right TV parameters.

I'm currently achieving this using one treeview for the whole UI structure, and another one (table-like) for displaying info on currently selected item (see my screenshot). Using the main tree, I can add, remove or change type of the items (via right-click menu), control item visibility (the "eye" icon like in Photoshop/GIMP and many other applications).

For adding new items, I've hacked together a rather naive ID generator which sort of works, although it's not completely in line with what I think it was intended for IDs, but again we have to consider that the program may be working with files edited by hand, which also don't strictly follow the developers intent.

From what I can tell, IDs were intended to be in the form XX000000 for pages and XXYY0000 for groups (no matter how deep in the tree those groups are), with only the lowest two bytes being used by all other item types, and in a way that a child items would respect that numbering in their own IDs. In practice, however, we could potentially encounter files that don't follow this convention, esp. the last part.

- Other features will be ID checking, renumbering, insertion, links to other files (images and otherwise).. auto udating, backups... whatever come to mind :D
Generally the idea is to make the INI file stable

Renumbering can be fully automagic if you reconstruct the tree after reading the file and then forget those [Gxx Iyyy] numbers: flattening the tree out again will give proper numbers. So in a sense renumbering would be as easy as open -> save (with a warning that numbers are wrong, of course).

Regarding ID checking, yeah. While I was drafting the parser, I quickly found out that I can't really read the file if I consider it an error if there are duplicate or incorrect IDs: MaGUI, for example, has several duplicates and one ID that wouldn't fit into 32 bits :) (not to belittle the work, it's a huge file, and it has been manually edited, after all). So it is indeed required to read the files in relaxed mode (allowing for some mistakes in files edited by hand) with some later warnings of some kind. Right now, for example, I highlight elements with duplicate IDs in red and unnamed elements in dark yellow (since that's not really an error).

Very cool work Guys.
:up:

:salute:

What are you programming in? C#?

I personally use C++ and Qt. The beauty of Qt is that it allows to create a very flexible interaction between data and its representation (the model/view paradigm). Plus it has a very nifty facility for rendering 2D scenes: all I had to do was construct some rectangles whenever the actual data said it has changed. Finalizing it would require additional work, sure, but most of the boilerplate is already taken care of by the framework.

If I can assist with any questions feel free to PM me.
I kind of know my way around the files.
:03:

Will certainly do :)

oh.. The dev kit is Masm32.

:o :rock:

vanjast, can I PM you as well for further discussion? Or should we keep it here so as much as possible would be public?

Madox58

12-26-13, 03:54 PM

I do C++ and did play with QT a bit. I never got into QT that much and tend to keep things very short and rough.
I'll answer anything I can and there's a bunch of people that can be called on to assist you Guys if needed.
:yeah:
As far as replaceing/copying S3D and how it works? I'd not waste the time when there's still a bunch of stuff you could address that S3D does not handle.

radcapricorn

12-26-13, 04:02 PM

I contemplated for a long time whether or not I should use D for this project. Sadly, I had to put it aside since UI libraries are not there yet, and it would be tremendous work to implement it all by hand. Though after vanjast said he uses Masm, I feel celestially humbled :D

Madox58

12-26-13, 04:11 PM

I dropped working Assembly around the release of Windows 1
:haha:

areo16

12-26-13, 07:18 PM

Fantastic!

:hmmm: Is that prudent? I mean, AFAICT the ini structure itself with those [Gxx Iyyy] identifiers just represents the actual UI tree (or forest, actually), but flattened backwards. These bracketed numbers don't present any meaningful info for editing, do they? Plus if you store them, you'd have to recalculate them for the whole subtree every time you add or remove UI elements, instead of just once when saving the file.

IDs (ItemID, ParentID), on the other hand, are a different matter, since they are pretty much responsible for the actual UI structure.

Backups are certainly a must. But what do you mean by "track"?

I'm currently achieving this using one treeview for the whole UI structure, and another one (table-like) for displaying info on currently selected item (see my screenshot). Using the main tree, I can add, remove or change type of the items (via right-click menu), control item visibility (the "eye" icon like in Photoshop/GIMP and many other applications).

For adding new items, I've hacked together a rather naive ID generator which sort of works, although it's not completely in line with what I think it was intended for IDs, but again we have to consider that the program may be working with files edited by hand, which also don't strictly follow the developers intent.

From what I can tell, IDs were intended to be in the form XX000000 for pages and XXYY0000 for groups (no matter how deep in the tree those groups are), with only the lowest two bytes being used by all other item types, and in a way that a child items would respect that numbering in their own IDs. In practice, however, we could potentially encounter files that don't follow this convention, esp. the last part.

Renumbering can be fully automagic if you reconstruct the tree after reading the file and then forget those [Gxx Iyyy] numbers: flattening the tree out again will give proper numbers. So in a sense renumbering would be as easy as open -> save (with a warning that numbers are wrong, of course).

Regarding ID checking, yeah. While I was drafting the parser, I quickly found out that I can't really read the file if I consider it an error if there are duplicate or incorrect IDs: MaGUI, for example, has several duplicates and one ID that wouldn't fit into 32 bits :) (not to belittle the work, it's a huge file, and it has been manually edited, after all). So it is indeed required to read the files in relaxed mode (allowing for some mistakes in files edited by hand) with some later warnings of some kind. Right now, for example, I highlight elements with duplicate IDs in red and unnamed elements in dark yellow (since that's not really an error).

:salute:

I personally use C++ and Qt. The beauty of Qt is that it allows to create a very flexible interaction between data and its representation (the model/view paradigm). Plus it has a very nifty facility for rendering 2D scenes: all I had to do was construct some rectangles whenever the actual data said it has changed. Finalizing it would require additional work, sure, but most of the boilerplate is already taken care of by the framework.

Will certainly do :)

:o :rock:

vanjast, can I PM you as well for further discussion? Or should we keep it here so as much as possible would be public?

I use C++ and Qt for my projects. Signals and slots, easy as pat. The Designer makes the whole process fun. I'm thankful I chose Qt over Visual Studio. But now Nokia is owned by Microsoft, so will Qt become unfree?

vanjast

12-27-13, 02:01 AM

As far as replaceing/copying S3D and how it works? I'd not waste the time when there's still a bunch of stuff you could address that S3D does not handle.
That is a point.. I'll only consider replacing it's functionality if I have nothing else to do... so it's a last resort thingy!! :)

:hmmm: Is that prudent? I mean, AFAICT the ini structure itself with those [Gxx Iyyy] identifiers just represents the actual UI tree (or forest, actually), but flattened backwards. These bracketed numbers don't present any meaningful info for editing, do they? Plus if you store them, you'd have to recalculate them for the whole subtree every time you add or remove UI elements, instead of just once when saving the file.

IDs (ItemID, ParentID), on the other hand, are a different matter, since they are pretty much responsible for the actual UI structure.
I've done it this way to keep the original INI structure and make reading/saving the INI straight forward - It's just a simple tree walk.
Maybe it'll also help the modder keep track of what he/she's doing.
No problem with the PMs

I've used a variety of dev kits MsC, C++, Visual Basic and Masm (and other similar embedded stuff) , but still gravitate to Masm - I like tinkering :). The structures of the languages are literally the same, as you have to conform to the WinApi anyway.

sublynx

12-28-13, 04:38 AM

All thumbs up for you guys :yeah:

radcapricorn

12-29-13, 09:44 AM

All thumbs up for you guys :yeah:

:salute:

I've done it this way to keep the original INI structure and make reading/saving the INI straight forward - It's just a simple tree walk.

But... The whole purpose of editing is to be able to change that structure. Why keep something that's gonna be altered anyway? Storing those entries will only force the application to perform renumbering every time the user adds, deletes or moves even a single UI item.

Even more, customized UIs (i.e. MaGUI, not sure about OLC) may have "invalid" [Gxx Iyyy] entries that for example don't contain ItemID or ParentID: the IDs are either commented out or missing. I assume this was done to "remove" items without having to renumber the whole groups. The game just seems to ignore these entries (at least I didn't see any error messages pop up).

Don't get me wrong. I'm not trying to convince you that my views regarding this are "correct". I'm just trying to understand if there are any gains in your approach that I don't see.

No problem with the PMs

Great! Though I'll probably start bothering you after the New Year :)

I've used a variety of dev kits MsC, C++, Visual Basic and Masm (and other similar embedded stuff) , but still gravitate to Masm - I like tinkering :). The structures of the languages are literally the same, as you have to conform to the WinApi anyway.

Surely you meant "data structures to pass to WinAPI are literally the same"? Because the languages are very, very different :)

---

Anyway, here's probably my final pre-New Year progress and discoveries. Material loading and rendering is mostly done. No font/text rendering yet. Fancy widgets like editboxes, listboxes, etc. are not rendered properly either, that for after the New Year.

In one of the recent threads Seeadler mentioned that there are some hardcoded UI pages. I probably should ask him if he knows of any pages in particular to avoid any further "surprises"; Privateer, maybe you also have some insight on this? Here's what I found today (vanilla menu.ini):

http://imageshack.us/a/img9/4272/nf97.png

That's "Page barracks" (G67 or 0x67000000). Note a whole lot of gibberish where the U-boat compartments should be. I have one of those "items" selected in the tree (it's highlighted with yellow dashed line on the graphical display).

At first I thought I had an error in my "Crop" computations, so I opened the tga those items are referencing (data/menu/data/comp-2.tga) and checked. Turns out that my app follows the Crop correctly, the regions just end up in the wrong areas of the image. Furthermore, the "comp-2.tga" is a compartments atlas for Type-II U-boat. There are other files for other types of boats, but they're not referenced anywhere in the menu.ini file.
Also note that the item itself has an ID of 0x27A50009, even though it's inside page 0x67000000. Now, page 0x27000000 is "Page binoculars", and thus shouldn't have anything to do with barracks. :doh: There are other items here that have their ID start with 0x27, so there's definitely something fishy going on.

This leads me to believe that this page is handled elsewhere (i.e. game code). If not completely, then at least item positions, material references and Crop parameters are ought to be changed by the game in order to display this page correctly for every type of U-boat.

There are also pages named "Equipment Icon", "Typ2", "Typ7", "Typ9" and "Typ21", but they're empty and just reference file "data/menu/menu_UBoats.ini" which simply doesn't exist :hmmm:

I'm not sure right now how to best deal with this.

Now to another page, "Page attack periscope" (same goes for "Page obs periscope"):

http://imageshack.us/a/img198/5356/fbc4.png

Note this "Glass" item in the Water Level group. It's laid out horizontally, even though in game it appears vertical. It has a Display mode of 5 ("Linear&Rotation"). Why exactly is it made like this, right now I only have a guess: the image itself is packed into the atlas in the bottom part of "data/menu/gui/periscope.tga", and it's laid out horizontally there. Since there's no way to turn horizontal image into vertical item (because instead of storing texture coordinates, the devs decided to store rectangles in the Crop parameter :/\\!!), they probably had to rely on the game engine to "rotate" the item into correct position. Now, why exactly does it get rotated (it doesn't seem to be connected to any "dial" in dials.cfg), is a mystery to me (unless it's hard-coded as well).

Seeadler

12-29-13, 01:56 PM

This leads me to believe that this page is handled elsewhere (i.e. game code). If not completely, then at least item positions, material references and Crop parameters are ought to be changed by the game in order to display this page correctly for every type of U-boat.

Here you run into the same problems as me during the creation of my own widescreen gui. It's the barracks page and the damage control page onboard which are handled in parts elsewhere ...I suppose in the SH3.exe.

radcapricorn

01-02-14, 09:11 AM

Thanks, Seeadler. So it seems this behavior is not that widespread among pages. That's good to know.

Now to some more fiddling. I've been investigating the various Display types for images, which included reading the existing guides and good old "see for yourself" method. Here's what I came up with regarding this parameter (warning, image with white font on transparent background):

http://imageshack.us/a/img836/5756/8q9k.png

That's how a source image (32x32 pixels) looks like in a 128x64 menu item in various Display modes. I've intentionally left the yellow selection border to better visualize the item's bounding rectangle.

For all modes except mode 0 (No Stretch), cropping rules apply: source image rectangle is "cut out" from the actual .tga image using first two "Crop" numbers as X,Y coordinates for top-left corner and last two "Crop" numbers as width and height (these numbers are normalized into [0,1] range where 0 means "top" or "left" and 1 means "full width" or "full height".

0 (No Stretch): Crop width and height are ignored, image is sampled from (Crop X, Crop Y) all the way to its edges. Image is not scaled in any way. If it ends up being smaller than the menu item, it is tiled (repeated) until it fills the whole menu item rectangle.

1 (Centered): The cropped rectangle is placed in the center of menu item's rectangle. Image is only scaled down, never up: if menu item's rectangle is shorter and/or more narrow than the source image, the image will be scaled to fit.

2 (Linear) and 5 (Linear&Rotation): Image is stretched to fill the whole menu item rectangle. The quality of resulting image depends on MatFlags (i.e. if flag 0x08 is set, bilinear filtering is used).

3 (Middle): Source is split into two rectangles vertically. Left half is placed (without stretching) in menu item's top-left corner, right half - in menu item's top-right corner. Space in-between is filled with the two-pixels-wide rectangle taken from the center of the source, stretched as needed. This may produce visual artifacts.

4 (All Directions): Source is split into four rectangles, each is placed (without stretching) into corresponding corners of the menu item. Space in-between the corners (i.e item border) is filled with corresponding borders of corner rectangles. Remaining space in the middle of the item is filled with a 2x2 rectangle taken from the center of the source, stretched as needed. This may produce visual artifacts. See for example "Page Message". The background of the message window uses this mode, and it is actually somewhat "uglified" because of that. But to be honest, I never ever noticed that in game until I started fiddling with these parameters :)

vanjast

01-03-14, 05:35 PM

Just a leetle update..
I've done a major shift and reshuffle to the 'front end'.
This is to allow individual modules (selectable from the green 'toolbar' buttons) to be added when ready.
Another week or two.. then it's back down to the nitty gritty...

I've been poking around a bit where you can add your own images/screen grabs to the background like a screen saver... just an added touch to your personal 'flavour'.
This current pic is a painting from John Hamilton's book 'War at Sea 1939-1945'.

$%&$%*^&*.... how do you display an image from Imageshack or Photobucket... the old way doesn't work any more ?? :doh:

http://imageshack.com/a/img196/5181/ytim.jpg

radcapricorn

01-04-14, 09:35 AM

how do you display an image from Imageshack or Photobucket... the old way doesn't work any more ?? :doh:

Like that? Just wrap the link in block, as usual (imageshack should give it to you this way already) ;) If you edit your post, I'll remove it from here. :up:

[img]http://imageshack.com/a/img196/5181/ytim.jpg

vanjast

01-04-14, 11:55 AM

Thanks, I tried that but it didn't work.
Must be my browser settings.

Consigliere

01-10-14, 12:51 AM

:salute:
That's "Page barracks" (G67 or 0x67000000). Note a whole lot of gibberish where the U-boat compartments should be...
This leads me to believe that this page is handled elsewhere (i.e. game code). If not completely, then at least item positions, material references and Crop parameters are ought to be changed by the game in order to display this page correctly for every type of U-boat.
I'm not sure right now how to best deal with this.

Hi, that's really cool that somebody would try to make a graphic menu.ini editor :)
For the barracs page.
First, it is used in port as barracs page and at sea as damage control & crew page.
Second, it does have "general" positions for compartments (not sure if it correlates with any sub type). And exact positions are indeed hardcoded.
I've wrote that info early here (http://www.subsim.com/radioroom/showpost.php?p=2072728&postcount=8). Check that thread for some info that probably could be usefull for your effort.

makman94

01-16-14, 12:25 PM

were have you been all this time guys ? this tool would have been a real treasure and would have save a lot of hours spended on the lines of menu_ini ! but ,as always, better now than...never !
from the pics that you have posted seems that it will be very handy , well done guys !:up:

ps: the sh5 has a menu_ini editor and i think that i read somewhere that it can be used for sh4 and sh3 too. never tried it though but have you guys checked if it can be adjusted to serve the needs of sh3's menu_ini ?

radcapricorn

01-16-14, 05:40 PM

Alas, we were elsewhere, makman94 :) Indeed hopefully such editor would be helpful even now, especially since there seems to be some demand for various resolutions (which are possible thanks to Seeadler's dll), and I can't even begin to imagine editing it all by hand for every possible resolution.

And indeed, sh5 does have a menu editor. A very clumsy and strange one, but nevertheless. As for utilizing it for previous Hunters... I don't know. The one time I tried to switch sh5's Data folder with sh3's one, it crashed as soon as I launched sh5.exe. As it should have. targas instead of dds, different fields in the ini itself... sh4 - maybe, I haven't tried. It *may* work there, because the file format is basically the same between sh4 and sh5 (they've introduced those mad Zones concept to allow for multiresolution support), and sh4 uses dds images as well... Still... sh5 stores each page in a separate file, while sh4 doesn't... In short, I wouldn't hold my breath :)

Oh, by the way, after a short discussion with vanjast, we've decided to start a separate thread to gather as much info as we can on sh's files, to keep this thread more focused on his tool itself. I'll be doing that sometime soon. Your input will be greately appreciated. And there are some things I have written down somewhere to ask you personally about what and why you did in your mods. ;) But that's for another thread.

@Consigliere: Sorry for the delayed reply. Thanks for your insight. All the little bits count!

Hitman

01-21-14, 05:29 PM

vanjast

01-23-14, 03:08 PM

My side is going to be delayed a bit.. I have to tackle some RL stuff.
' I'll be baaack '
:D

Meridian

08-02-15, 11:26 AM

Did anything come of this or did it get shelved permanently ?