Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - balketh

Pages: [1]
1
Three things to report: A bug discovered in playing 3.81 with this mod, and two small fixes for odds problem in the mod!

One: I seem to have found a bug when crafting a dip net for ore scooping.

Attempting to craft a dip net using decent quality cloth and perfect quality cord from BAC resulted in an error that said: "Bug in LoydettyTarvike() function. Report!" The dip net itself functions fine when used with the BAC ore scoop option, but insists that it has no fishing hook and asks for one if (a)ctivated.

Two: I think I've worked out why some recipes like in BAC_Textilecraft - specifically recipes like the Loom, and the Weave Cloth options, fail to allow the user to select anything other than the exact quantity of yarn or cord required, despite having the [nominlen] tag.

When Arimon added the [nominlen] tag in their 3.7x update, I think they added it incorrectly, as tag order seems matters: they placed [nominlen] AFTER [remove], which seems to cause the game to try and fully remove the exact length (or weight) of item before acknowledging the [nominlen] tag, which means it refuses to allow for multiple pieces to be used. This is a guess, because in other recipes, like the Nettle Apron from BAC_Clothing, the [nominlen] tag is placed after the [remove] tag for their yarn entry, but the recipe accepts smaller yarn lengths as per the correct function of [nominlen]. It may have something do with the fact that the apron's yarn ingredient is a wildcard, where as the Weave Cloth ingredients are not. Unsure.

However, I have tested and confirmed that it works: simply shifting the [nominlen] tag to be before the [remove] tag causes the recipes to allow for multiple lengths/weights to be selected, much like other default crafts.

I have confirmed that this change also returns any unused materials to your inventory as per any other style of this craft. This completely removes the need for any recipes that specify "Use exact length, surplus is lost.". I'm currently testing this bug across other uses of [nominlen] to see if any others aren't working, and fixing accordingly. Will report if I find anything else.

Three: I also intend to poke around more in BAC's files and clean up a lot of the descriptive text formatting. In doing so, I learned why the descriptive text tag doesn't seem to work right half the time, causing many inconsistencies and difficulties in use in BAC's item text display in crafting.

The descriptive text tag can be used in two different ways:

'+as weights for the warps' - this version has the + on the inside of the ''s, which simply causes the descriptive text to be added to the end of the ingredient's name. "Stone" becomes "Stone as weights for the warps".

+'as weights for the warps' - this version is different, with the + on the outside of the ''s. This version does not show the ingredient's name at all in the display, and is mostly for using with {[TERRAIN:word]} tags to hide the code part. "[TERRAIN:barren]" would become "as weights for the warps", as would "Stone", unlike above. This is useful for placing more ambiguous/concise ingredient instructional text in place of the full name of an ingredient, while hiding unsightly wildcard and TERRAIN/TILE tags.

By moving the + outside of the ''s for all descriptive texts with visible tags (and a standardization pass, maybe), the ingredient lists for many recipes could be much more readable and easier to intuitively discover and use, in the absence of detailed encyclopaedia entries for BAC items and the like.

I've some regex experience, so I'll be playing around with making some careful cleaning passes of BAC display text and neatness, and see if I can't improve the foundations a bit for everyone. No promises, but it might help.

Cheers! Hope this has been helpful.

2
Suggestions / Nested Submenus?
« on: September 20, 2023, 07:11:24 PM »
Hi!

Long time player, first time really delving into mods and things, discovering the ease with which modding can be done.

I have an odd suggestion, one I can't find any other discussion of in searching.

I don't know exactly how Menus and Submenus work in the hard code of the game. Many are hardcoded due to workarounds and requirements of new systems, such as the new arrow creation system. This has, it seems, for many years, caused endless headaches for modders. From an external, modding-only perspective, it looks like Menus are created in menudef_[YourModHere].txt files, and a single layer of Submenus are then defineable in their respective diy/biy text files.

My suggestion is about creating nested submenus. This would likely solve many organisational issues with the otherwise limited menu space.

A nested submenu would simply be some kind of entry into an existing submenu document that isn't a recipe, but instead another submenu. Whether in another text file, or nested in the same file as the ur-menu, submenus would allow for much more organised and less cluttered submenus, especially given the slow increase in content over time in the base game, as well as the nightmarish amounts of menu entries in mods like BAC (spirits protect you if you want to use BAC and some other mods, too!)

Changing the number of displayable menu entries is, I would guess, easier said than done, which would be why it hasn't been done.

Hence, the suggestion: nested submenus.

Even just the ability to nest a single new set of submenus within the existing submenu layer would increase the number of total menu options available to the base game and modders alike, by 25x, or over 15000 new menu entries available to everyone.

Thank you for reading my suggestion. I hope, if nothing else, it inspires some improvement in this wonderful experience of a game.

Pages: [1]