Why does each 'craftable' item has to be its own actual item? Could you not make something like, where if you pick up an apple, a script keeps track of how many you have, and instead of selecting individual items from a list when you cook them, you could just approach a camp fire, hit A to activate it and then be given a list of items you can craft, based on the number of supplies you've picked up? The ones you don't have enough craftable items for could be greyed out or not visible.
I'm not suggesting that this should be possible, I have no idea, I'm just throwing things out there.
Don't forget that you can use global arrays to store more items than the built in item system can hold. It might be kind of insane, but some scripters have proven that heavy duty scripting can go a LONG way past ZC's apparent limitations.
This would be my approach. I would store all the consumable items, and weapons, in arrays; and all the products of cooking in their own; then script menus to access them. You can easily toss a tile on a fake item and display it, even on the passive subscreen, without needing a legitimate item.
One of my quests has in excess of 350 'items', and I had to go this route anyway.
When I revised itemdata, item property management was one of the goals. I wanted to be able to have a set of generic items, and allow the scripter to set their properties at any time, so, you could for example, have ten cooked items in a quest, all generic, using a specific item class; then when Link cooks, the script that generates the type of food, assigns a tile, a script, Flags[5], Attributes[10], and other stuff to the legitimate item, and a global script can assign the item properties based on those inputs and the class, when the item is used.
Else, and item script could do similar.
That said, even in 2.50.x, you can expand inventory to unbelievable proportions.
The harder bit in all of this, is weapon vulnerability, which is arguably the most hated aspect of the BotW mechanics. Other stuff, such as climbing terrain, stamina, crossing hard terrain, and the hang glider, could all be simulated in very basic ways. We had a nice little ideas fest in chat on this, and there are several approaches that would work, but you need to rely on the imagination of the player. I
would use the simplified maps of Dragn Quest or Final Fantasy games, to show terrain, and give each type of terrain its own fake Z, and store a fake Z for Link, along with a stamina value. When Link encounters a mountain, instead of it being solid, it slows his rate of movement, and drains his stamina. If Link is trapped climbing, and runs out of stamina, he loses HP until he dies.
If Link is on a mountain, hill, or tree tile, he can use the hang-glider to coast a distance of n tiles based on n2 fake Z, and must land on a tile with a lower Z than the Z of the tile from which he descended, unless the tile is <= 2 spaces away. I could likely write up this fake Z hang-glider stuff in a day or two, if I ever find the time, merely to demonstrate the idea.
On another note, I would advise against downloading the binary file in that YouTube Link, until as a community we know that it is a safe file. It could easily be spyware of some kind, as I presume that it is not open-source.
If the source is available, we should review, compile, and test it; then archive it if it is clean.
Edited by ZoriaRPG, 12 May 2017 - 11:18 PM.