ZoneBuilder: Documenting issues with menus

[diamante0018]

Currently building a menulist with ZoneBuilder seems to lead to a guaranteed crash as it has always behaved this way.

However, it appears saving a single menu via the zone_source CSV is possible because it skips the code that saves the menulist to fastfile. This would be considered insufficient because menus are not supposed to be saved to a zone this way as the menulist is supposed to load menus. (meaning one menulist definition per zone.csv which then loads all the menus)

Other inconsistencies with IW4x's parsers are the following:

loadmenu does not support brackets around the name for the menu

menu names are hardcoded to be ui_mp/ meaning that for eons modders may have created menus that are now incompatible with other official modding tools (t4,iw3,t5)

[Rackover]

Proper pointer support in menu writing code would solve a lot of these crashes actually! Menu definitions can be recursive and self-referencing in all sorts of funny ways, having proper menu writing in the zone would be a very good start 🙂

[diamante0018]

So, I was able to build this mod with oat

iw4x_menu_mod.zip

On IW4x when edited to work with the hard-coded paths the following will happen.

The game will somehow try to save so many menus that are completely unrelated to the issue at hand! Its not a matter of eliminating data duplication in the save code (although it would be nice) the problem is IW4x can and will attempt to save all custom menus loaded in memory even when I'm simply trying to save one single menufile!

[diamante0018]

One Menulist and one menu !

Somehow the game now tries to load up menus like 'main' and main_text and that's just weird

This is most definitely not supposed to happen, the zb is trying to save menus that is not even supposed to load

[diamante0018]

No wonder I was left baffled when the crash occurred on this weird csv file that was mentioned nowhere in my menu

[Rackover]

Somehow the game now tries to load up menus like 'main' and main_text and that's just weird

It's because they're in the IWDs. So what you're seeing here is not "Zonebuilder menu loading code", it's IW4x raw menu loading code, and the reason it's loading half the planet is because that's what IW4x does - you put a menu somewhere in a folder and it is expected to load.
The bug is rather that, as you said, Zonebuilder tries to save them as it cannot tell apart menus it loaded as part of the ZB CSV and menus it loaded as part of IW4x normal behaviour. Feel free to implement custom handling for this because menus will probably not be a part of IW4OF ever, so a IW4x-Specific solution is what we probably want in that case 🎉

[diamante0018]

Ah I was able to fix it by duplicating my files on disk
turns out ZB looks for a non existent file called default_menu.menu so when I made a copy of my menu on disk it loaded and it saved my menulist without bugging

[diamante0018]

Somehow the game now tries to load up menus like 'main' and main_text and that's just weird

It's because they're in the IWDs. So what you're seeing here is not "Zonebuilder menu loading code", it's IW4x raw menu loading code, and the reason it's loading half the planet is because that's what IW4x does - you put a menu somewhere in a folder and it is expected to load. The bug is rather that, as you said, Zonebuilder tries to save them as it cannot tell apart menus it loaded as part of the ZB CSV and menus it loaded as part of IW4x normal behaviour. Feel free to implement custom handling for this because menus will probably not be a part of IW4OF ever, so a IW4x-Specific solution is what we probably want in that case 🎉

Issues is still not that, that is ZB panicking behaviour, it can save menulists I just discovered however the behaviour is very sinister

Basically it goes like this
menulist.txt will load ui_mp/default.menu
ZB will try to then parse menulist.txt and sees it has one menu file to load
loads it without issue -> will now attempt to save default_menu.menu ??? (it magically added a _menu) to the file name -> file does nnot exist on disk, game explodes as ZB panics and tries to save to my mod all the menus loaded from IWDs

Magical workaround, duplicate on disk these two files ZB can find them and finishes saving my mod without issues!

[diamante0018]

We made more progress on the Discord server, there we documented how ZB is actually capable of linking a menulist with 'some' menus but is expected to crash when 'a lot' are used due to code that can be improved in the save code.

There are strong requirements to get ZB to work.

• comply with "illegal" syntax that is compatible with official mod tools!
• each menu must be defined in its own file (can have itemdefs inside of it ofc) and the menu name and file name must match

The illegal syntax is as follows:

In the CSV the menu list is expected to be defined as menufile,<menu> where menu is actually just a name without ui_mp/ or the .menu extension.
In fact, ZB cannot currently accept any other extension because the path is hardcoded to always take what is being defined in the csv and prepending ui_mp/ and appending .menu extension

the loadmenu directive inside a menu or a menulist, also takes just one name and the iw4x client will force the path by adding ui_mp and adding a .menu extension.

Why is this stuff in the client? because IW4x never had such code tested and the priority was to override single menu assets from disk without actually overriding entire menulists
that is why in cod4 mod tools asset list you can have

menulist,ui/default.menu
menu,ui_mp/default_menu
however, this will not work with ZB because the filename requirement is not met.

When ZB can't find a single menu file (to override) it will panic and enter in a weird state where it tries to save every single menu from the iw4x iwds ending up crashing eventually.

[Rackover]

however, this will not work with ZB

Do note that the CoD4 asset list is not a zone_source, it's just an asset dump. Asset lists, as far as I know, are not buildable with CoD4 mod tools. They are not expected to be buildable with ZB either.