See likes
See likes given/taken
| Post info | No. of Likes |
|---|---|
|
Re: Make Menu only for Modded items = saving BAC and other large mods
I would be satisfied with a hypothetical 'O' *MOD* parent menu. If the maximum limit were 25 submenus multiplied by 25 recipes per submenu, that should be room enough to reserve 625 modded entries. (And the option of putting additional entries under *MAKE* and *COOKERY* menus will still exist, even if later game updates do deplete available space for custom submenus.) But I'm wondering whether the existing menudef structure will require a new file prefix to handle items under *MOD*. Seeing that *MAKE* needs diy_, *COOKERY* needs cookery_, and the building skill menu needs biy_, it would be natural for *MOD* to need mod_. Rather than completely cloning diy_ capabilities, it would be nice if mod_ files could, for example, extend the building entries. Currently, the building menu can only handle one recipe per construction/terrain tile type. BAC offers alternate .Shelter. recipes, but each of these must be enabled/disabled manually by editing/erasing the biy_ file prefix name in order to overwrite the default recipe when the player deems the situation to be appropriate. But this is not the only friction involved with biy mods. If the player were to leave the modded recipe active, interacting with constructions generated on the zoom-in map would result in unintended consequences - such as failing to return the expected raw materials upon deconstruction when the game's object dictionary doesn't recognize modded item names. In this case, it would be preferable for modded buildings built by the player to be considered distinct from buildings generated according to the default recipe. May 03, 2024, 10:41:12 PM |
1 |
Re: Make Menu only for Modded items = saving BAC and other large mods
I would be satisfied with a hypothetical 'O' *MOD* parent menu. If the maximum limit were 25 submenus multiplied by 25 recipes per submenu, that should be room enough to reserve 625 modded entries. Yes, if there was a transition to separate make menu for mods the file name changes would be necessary to distinguish the mods from the original game crafting entries. It could be also that the original crafts would exists as urw_diy_somethingsomething.txt and modded as mod_diy_somethingsomething.txt etc. To make everything reliable there would need to be the same logic and separation for cookery, buildings and flora as well. 625 entries is a lot but everything can be exceeded. To have a long-term solution I believe the system would need to allow different mods to co-exists and overwrite each others entries if necessary. Many players do little snippet modding for slight adjustments to small set of items. Let's imagine there would be a mod that modifies many items, including for example a wooden cup. Then let's imagine there's a player who likes to use the said mod but prefers their own adjustments to wooden containers. Now I think there would need to be a way for the imaginary "wooden containers mod" to be installed on top of the other existing mods, even though they would modified the exact same entries. Otherwise investing time to code a new craft menu would be pretty much a stillborn addition. Luckily there are many way to cope with the said situation, but they are a bit costly to code. One option would be to run checks for the mod files when the game starts. The game would then notify there's a modified "wooden cup" item within 1. big mod, 2. mediocre mod, 3. wooden containers mod. Which modification you prefer to use? The player would then choose their wooden containers mod, and the modders make menu option for "wooden cup" would be pulled out exclusively from that mod. There could be also ways to set personal priority level for mods, so that the entries in player's highest priority mod would overwrite the others. In the above example the player would be able to set their "wooden containers mod" as priority level 1. And several other ways too. With something like this in addition to possible file name changes the "[r]epeat a craft" system would also need to be reworked to some extent. Now it's simple and easy as the repeat option just browses all the files to search for the item name, and repeats the crafting of that. With the overlapping (and somehow cleverly prioritized) mods together with the original game crafting files the repeat would need to remember from which files the said crafting was initiated. Quote Rather than completely cloning diy_ capabilities, it would be nice if mod_ files could, for example, extend the building entries. Currently, the building menu can only handle one recipe per construction/terrain tile type. BAC offers alternate .Shelter. recipes, but each of these must be enabled/disabled manually by editing/erasing the biy_ file prefix name in order to overwrite the default recipe when the player deems the situation to be appropriate. But this is not the only friction involved with biy mods. Yes, well, the modding works as it works and surely it can lead to mess if it's used in a fashion it's not intended for. Modding is fun and there really could options for so many things that I could use all my time for that alone. I may be repeating myself, but I'm foremostly developing the game rather than a modding script/engine. There are games that are built up from a modding perspective and prioritize that, but we've got our roots somewhere else and follow a bit different path. Nevertheless, we've got the modding in the game - among a few other features - and the suggestions are always at least read, sometimes even discussed and fulfilled - if they fit in the big picture. May 04, 2024, 12:31:51 PM |
1 |
|
reflections from a modding enthusiast on external assets vs. core
Thanks for providing more insight on what remodeling mod support might look like from a developer's perspective. It really is a beast that requires careful thinking through several possible modes of approach (if it must be approached at all...!) I currently use Weathereye's Mod Loader for Windows to set the priority of my active mods and perform other simple mod management tasks. This tool would surely be at risk of breaking if a major rewrite of game versus modding data should be undertaken, but the pain of its loss will be lessened if mod management were to be handled natively. (The rest of this post is largely a testimonial about how I use the the mod loader.) Graphic edits make up the bulk of my modlist in determining overwrite priority. Outside of my game directory, I maintain a spreadsheet that keeps track of which mod source should be overwriting what image file. But once I have the modlist order sorted out, my method veers into micromanagement: whatever images not being used in my load order get moved to the mod's name-root folder to ensure these specific files never interact with truetile + truegfx subfolders. This step may seem redundant since overwrite priority is in place, but at least I can go browsing through fairly tidy subfolders. One ardent wish I have on the graphics-side of modding is support for additional truetile variant indices. As much as I enjoy seeing the sprite artworks that members of the community were inspired to create for replacer mods, the impossibility of simultaneously using all these files feels unfortunate. For instance, tree terrain tiles are limited to displaying 2-3 variants at most (including broadleaf trees in winter mode), but I would love to wander through woodlands populated with a mix of Krutzel's Spirited Sprites having both its tall and standard-height trees alongside kullervo's trees. As for crafting, it's honestly a lot easier for me to dump a distribution of BAC (or other recipe-heavy mods) into a separate folder where it remains inactive but still available as reference material. With my active "BAC lite" folder, I'm at liberty to adapt excerpts from the parent mod and reorganize recipes according to my own idiosyncratic sense of order. I give a similar treatment to new releases of URW: my Steam installation stays clean, previous versions are backed up in compressed folders, and the copy of my updated directory with the external mod loader will have as many or as few add-ons as I desire depending on which modlist is enabled. In general, I consider mod-induced compatibility issues to be a natural consequence that players will inevitably struggle with. Building around the existing architecture is the furthest extent of what the majority of us are capable of; both the naive newcomer and the returning veteran will be in for a shock when they realize a particular modded setup happens to clash with the introduction of new standards in the metaphorical 'building regulations'. I try to keep my own build flexible, but there's no pressure on me because I'm the primary beneficiary whom my modding endeavors are centred around. Brygun's passion for documenting and preserving the self-sufficiency tradition has an unfortunate side-effect of painting a target on his back since it's his username that people mainly associate with the modpack (and thus, there'll be someone available to blame when something goes wrong, however unfair that attitude is.) Now, it certainly won't be detrimental for a person to learn how to read the modding syntax or do tests to figure out how to troubleshoot, but not everybody is equally motivated to invest in these skills 'just to play a game'. This subsection of players will definitely miss out on a lot of gems that are found in the game's primary source of documentation: news.txt It surely adds to one's enjoyment to find out how things work under the hood, but even without the external assets URW is super engaging on its own. (I personally spent 3 years completely ignorant of mods because reading forums seemed less interesting at the time...) Streamlining mod integrations may sound nice in theory, but I'm worried that it will be a rocky road for a while before we reach a smooth grade. Rolling towards the destination might not feel worth the effort if the external tools I'm using now should cease to function before a replacement is ready - but a fear of future discomfort oughtn't impede me from enjoying what already exists in the present (especially since I exercised responsibility for preserving my current 'quality of life' through having a bunch of backups.) May 05, 2024, 03:05:03 AM |
1 |
|
Re: Make Menu only for Modded items = saving BAC and other large mods
As a player, when I'm in the middle of a longer modding project and some of my items are no longer compatible, I just add a new temporary item to convert what I have into what I need. Like this: Code: [Select] .Stoney arrowhead. "Stone arrowhead" [effort:0] *CARPENTRY* |0| /1m/ [patch:5]This bit of code took all the old modded arrowheads which didn't work with the new arrows code, and very quickly converted them all into the new vanilla stone arrowheads. May 07, 2024, 06:53:42 AM |
1 |
|
Re: Make Menu only for Modded items = saving BAC and other large mods
Welp, time to also throw in my two cents - I'm one of the old legacy people who have purchased it, back in ye olden days, so I feel like I've got some experience under my belt. I eventually stumbled upon the BAC mod while looking on how to enhance my gameplay, given I've been playing UrW for quite a while, and as a result I basically never play without it anymore. Why? The game as it stands, is what you make of it: no overarching story, no fun little quirkiness to uncover, just pure, unadulterated survival, and that is great. HOWEVER - to be long time invested into something like that, the game needs to have enough content to support the long gamespan we are talking about in those runs, which is where the BAC mod comes in. It appears that the game as of right now is simply limited in amount of keyspaces available to properly distribute all the menus and submenus when one wants to run the game with a big addition mod like BAC. Is it a problem now for vanilla? No, but depending on how UrW is going to be developing moving forward, this would eventually become an issue either way, simply because there is only so many combinations of menu and submenu buttons available, and a mod that adds quite a lot of things faithful to the setting has managed to approach this limit. I am however very much agreeing with Erkka that it should be modders making sure the mod is compatible with the game evolving, but since the amount of mod entries have grown to absolutely massive sizes, with Brygun basically curating the quite huge BAC mod all by himself, this is gonna take a good while. And until either a deeper submenu system is coded in that allows to have an extra level deeper of menus to access, or an entirely different mod make menu as requested, where the entirety of mods can be placed in, this is also going to repeat itself - And this takes time. BAC wasn't even done fully converting the entries to the by then still out 3.83 when 3.84 dropped from what I've seen, as I have seen still additions just days prior the new update coming. And I have to say, it does not feel unreasonable to make a request towards the developers, accomodating the ever growing modding community because of the games limits. When BAC has already reached the point of having to scrap portations, as well as fusing components like nails and rivets, then that only really shows that this can truly become an issue going forward. May 07, 2024, 07:34:52 PM |
1 |
|
Re: Make Menu only for Modded items = saving BAC and other large mods
Just wanted to post on this- i think an additional key for modded menus is a good idea. I implemented my own version in my old mod extender project, using the ~ key would bring up an external menu with mods and their designated key. then, when one of the keys gets activated, it would get the menu def information and write it into the games menu def files, save, and then macro the keys into that menu, so you dont need to manually open up the crafting menu and all that, allows for infinite menus, as you're able to exchange mod menus with a single key (i used Z) Could probably be done with a simple keyboard/autohotkey interface if you want to avoid UI, which is the way i had mine setup. Idk if this is useful to anyone, but to give you an idea of how it works in code: Code: [Select] private void ModManager_KeyDown(object sender, KeyEventArgs e) // Hide/Show extended menus
May 08, 2024, 06:10:37 AM |
1 |
|
Re: Make Menu only for Modded items = saving BAC and other large mods
Brygun, the preload of mods was in Sami’s post; response 7, to Galgana’s question about biy_glossary limitations I.e. returning original recipe ingredients, not the currently loaded recipes ingredients. Currently if you build vanilla shelter, then comment that out, enable punt shelter from BAC, deconstruct the shelter; you’ll get punt shelter ingredients, not 3 slender trunks and 20 spruce twigs that the shelter was originally built with.
May 09, 2024, 05:54:50 AM |
1 |