UnReal World forums
UnReal World => Suggestions => Topic started by: Brygun on April 29, 2024, 09:00:53 PM
-
Mod collision continues to happen with the 3.83 and 3.84 updates with it going to continue to cause conflicts with large mods like the BAC
If you could give us a single key for a craft menu only for modded items it would help greatly. The large BAC mod could be fired up that way with its existing ways of making axes, bows and so on that date back to Bouddia and Rain.
The existing craft menu could remain the same and modders could add to it like now, though knowing that future updates may cause collisons.
Collisions as discussed before happen when updates add items to menus that cause overflow when the total of (new vanilla plus mod items) exceeds the allowed amounts and in the case of the Hafted menu a letter (in this case "H") already being used by a mod.
There are 3 solutions.
= Tiered menu where you open crafting then choose a master menu A, B, C etc but this hasn't been implemented as a heavy coding change
= Co-ordinating the top menu of letters with a large mode like BAC which has already puzzled out things but clearly with "H" for a couple of hafting items isn't of interest
= Give modders a one letter for a seperate modders craft menu. This seems plausible and with limited coding needs. Simply put instead of the "M" for make another letter is u sed to open another craft menu. A craft menu that the dev >NEVER< puts vanilla items into. Instead the large modders can use this as a safe space to figure out on our own large collections such as BAC.
Frankly the ongoing additions of a few items like hand axes and bow making has been modded since long before BAC dating to Bouddia and Rain years ago. I agree that added pausable crafting is a good thing and in time Saami should integrate many of the crafts into vanilla. What is killing the game of those using large mods, and many do use BAC, is the mod collision along the way.
The "modder craft menu" is a more specific lower coding requirement that would support with the large mods. Unreal has long had a commitment and encouragement to modding, such as the initial webpage hosting. Its been years since the first days. You have the success of large mods. For them to function they need to avoid mod collison.
A single separate menu would work for this.
-
Without getting further into this a few things come to my mind...
Now I haven't tried BAC or other mods, except for snippets provided for bugfixing, but if it's eating up all the space there must be hundreds of entries to make - right?
If that's the case I'm just wondering are they all absolutely necessary... or could there room for quality over quantity approach, removal of some probably excess curiosities, streamlining recipes to meet more with the existing resources or make categories, and so on?
(Also, are there any "other large mods" that are found troublesome to keep up with the recent updates to the game?)
-
The number of entries is likely in the hundreds yes. Its name include "and community" as there is ALOT of recipes from many of our community in it. I acted as the primary but not only curator. Its how upto 3.82 the BAC combined kept alive mods like Rain's Ironworking, Endive Survival, Bouddia, Weaving, my own collection of oddities, Iago's whittling and many others.
The make menu allows IIRC 24 letters. Of the 24 letters allowed BAC uses 22 with only about 2 unused. Thus any update which makes use of a new letter, like hafting did in 3.83 creates collision with the mod.
It has the production steps for gathering, smelting, forging iron to make axes, swords, metal armor, helms. There was bow making and arrow making. More items included wool making for wool clothing, retting and so on to end up with cloth clothing and bags, clay crafting for pots and containers. A collection of cooking recipes as well.
Overall...
I encourage and expect the ongoing vanilla adds to pull in the mod versions of things, like bow making now, into vanilla recipes. That's a good thing.
The recipes at the times pushed the limits of what we could do like no step could take more than 8 hours due to needing food and water. One affect is that to have longer processes, like making a canoe, they had to be broken down into 8 hour steps each needing a menu item entry. Now Saami has nicely added pausable crafting. So there is some long projects which could be updated.
The challenge is as new vanilla crafting methods (nets, axes, bows) there is both space needed and a duality that exists. Since a BAC install will overwrite some menus reports are players get confused as to if they dehaft with the new vanilla system they then end up in a BAC menu which doesn't use the same thing and vice versa.
So to avoid the large mod overlap with the least programming it would be good if we could have a modders second letter for making items. We could just stick large mods like BAC there. Then when the game updates, as it should, with new updated items players current games would know to continue with vanilla or BAC. Example being axe making and rehafting are not compatible between 3.82 BAC and 3.82 vanilla.
>>>
If you do want to at least see how much was in BAC it was last updated to 3.82 so please use that version of the game. There is short adjustment needed for 3.83. No updating has been put forward for 3.84. Even a few minutes would show you the extent to what BAC grew into.
-
The number of entries is likely in the hundreds yes.
..
The make menu allows IIRC 24 letters. Of the 24 letters allowed BAC uses 22 with only about 2 unused. Thus any update which makes use of a new letter, like hafting did in 3.83 creates collision with the mod.
..
It has the production steps for gathering, smelting, forging iron to make axes, swords, metal armor, helms. There was bow making and arrow making. More items included wool making for wool clothing, retting and so on to end up with cloth clothing and bags, clay crafting for pots and containers. A collection of cooking recipes as well.
Okay, so it's hundreds, thus I believe my pondering is valid. (Are they are absolutely necessary... or could there room for quality over quantity approach, removal of some probably excess curiosities, streamlining recipes to meet more with the existing resources or make categories, and so on?)
And yes of course, any update which uses a new letter reserves that letter, it's not a surprise, but there haven't been that many new letters over the past years so I don't suspect re-organizing few letters is a problem. And as the system is as it is now, the easiest solution to fix the mod to work with the current updates is to streamline, reduce and re-organize.
I encourage and expect the ongoing vanilla adds to pull in the mod versions of things, like bow making now, into vanilla recipes. That's a good thing.|/quote]
As mentioned we don't actually follow mods. Also from dev's point of view adding new items with new mechanics that actually tie them into game world within the core level needs to be done with old-school programming. Modding is player's thing.
The challenge is as new vanilla crafting methods (nets, axes, bows) there is both space needed and a duality that exists. Since a BAC install will overwrite some menus reports are players get confused as to if they dehaft with the new vanilla system they then end up in a BAC menu which doesn't use the same thing and vice versa.
Hmm. Why won't you remove the duality from BAC then? If there is somekind of hafting in BAC, what's the reason for still keeping it in there and reserving the space when there's proper in-game hafting mechanics to use.
If the intention is to have modded counterpart for everything, and not to utilize the existing resources and mechanics, it's doomed way anyway. For example proper hafting where the item is treated in the game as the head and haft can't be created with modding. Surely an illusion of it can be created, but neglecting the item handling etc. provided by the game may lead into unexpected problems during the gameplay. And same goes for variety of items. If all of the existing, especially the hardcoded stuff, is replace by just modding it's actively breaking some game elements here and there.
So to avoid the large mod overlap with the least programming it would be good if we could have a modders second letter for making items. We could just stick large mods like BAC there. Then when the game updates, as it should, with new updated items players current games would know to continue with vanilla or BAC. Example being axe making and rehafting are not compatible between 3.82 BAC and 3.82 vanilla.
As we're very occupied with the pausable and crafting additions I don't have time to seriously consider the options, but I'll digest things when time allows.
If you do want to at least see how much was in BAC it was last updated to 3.82 so please use that version of the game. There is short adjustment needed for 3.83. No updating has been put forward for 3.84. Even a few minutes would show you the extent to what BAC grew into.
I'll have a look when time allows, and will get back then probably with better insight of the possible solutions to remedy things - which I'm afraid now also calls for cleaning up the mod code too. I get there's lots of entries, and it's been lots of work to come up with, but for me personally things that advertise themselves as having 15,000+ items and 7000+ different trinkets are are turn off for me. That's just me, though.
-
The challenge is as new vanilla crafting methods (nets, axes, bows) there is both space needed and a duality that exists. Since a BAC install will overwrite some menus reports are players get confused as to if they dehaft with the new vanilla system they then end up in a BAC menu which doesn't use the same thing and vice versa.
Hmm. Why won't you remove the duality from BAC then? If there is somekind of hafting in BAC, what's the reason for still keeping it in there and reserving the space when there's proper in-game hafting mechanics to use.
If the intention is to have modded counterpart for everything, and not to utilize the existing resources and mechanics, it's doomed way anyway.
Cart <> Horse debate.
As the ancestral mods go back to Rain's ironworking it added the ability to make most of the in game items. This being done at a time when vanilla had no way to do so.
I do think adding into vanilla making items is good. Your own views on times, resources and coding like haft will take of course be different and that's fine. Things like pausable crafting didn't exist so we had to limit times too.
Eventually after each update the duplications would in time be dropped. However at the time of release there is a lot of jumbled things. Like BAC axe heads aren't the new vanilla axe heads. BAC axe hafts aren't the new vanilla axe hafts. Players in the middle of play get confused, frustrated and might not even see the new vanilla menus depending on which installs over the other.
Having an extra letter would let the large mod items exist separately. On a new vanilla update both could exist without that jumble. In time the mod could be updated and remove what is now duplicated by new vanilla code. Example 3.84 added more bows which were already craftable by the mods.
There is also a matter of who will be updating BAC as it might not be myself in the next few cycles. It is set up as a "community" collective and there has been other caretakers along the way. The one extra button is something that gives the large mod time to sort out without thrashing existing games when ongoing vanilla updates creates new duplicates are new principles. Principles like the cordage update and pausable crafts.
-
Hmm. Why won't you remove the duality from BAC then? If there is somekind of hafting in BAC, what's the reason for still keeping it in there and reserving the space when there's proper in-game hafting mechanics to use.
If the intention is to have modded counterpart for everything, and not to utilize the existing resources and mechanics, it's doomed way anyway.
Cart <> Horse debate.
As the ancestral mods go back to Rain's ironworking it added the ability to make most of the in game items. This being done at a time when vanilla had no way to do so.
I do think adding into vanilla making items is good. Your own views on times, resources and coding like haft will take of course be different and that's fine. Things like pausable crafting didn't exist so we had to limit times too.
For me there's a bit strange, topsy-turvy and unpleasant attitude here, so maybe I'll rest my case and the mod community can decide whether to streamline or not to streamline, now or in the future.
--
So back to business, and now if there are modders reading this, you can pitch in. Whatever gets done with modding it has to serve large audience so custom solutions from one mods perspective aren't fair nor fruitful additions.
A suggestion was to add separate craft menu for mods to use. Right? Let's make sure I understand the proposed suggestion correctly and then brainstorm as necessary.
So, let's say we'll make a letter O to open a blank make menu, which you can then fill with modded stuff like the current Make menu. And this would be menu that is reserved for mods only. The game craftings would appear in the exisiting Make menu, like currently. Now, if you would then fill this one modders make menu (O) with one big mod it would be..well..full. If there was a few smaller mods that you would like to put there, with custom menu entries or keys even, they would get messed up and tangled together.
If implemented like this it doesn't sound like a plausible long-term solution, or am I not understanding the suggestion?
-
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.
-
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_.
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.
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.
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.
-
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 (https://www.unrealworld.fi/forums/index.php?topic=67.0) 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 (https://www.unrealworld.fi/forums/index.php?topic=6897.0) having both its tall and standard-height trees alongside kullervo's trees (https://www.unrealworld.fi/forums/index.php?topic=1778.0).
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.)
-
No offense was intended. This was about the history of modding which you always made an available part of Unreal World. Many suggestions and possible updates exist for any game. When an update is developed and others not there will always be some different views on which one to do next or how it was done.
>>>
On the ancestral mods...
To phrase differently players making axes, bows, lamellar armor was added by mods for years. Rain's ironworking is an example. Since Rain wrote that mod various game updates have made his code not work or miss key changes like the introduction of cord lengths. Keeping Rain's going has been part of the BAC by updating those recipes to the current mod language.
As an example when the blacksmithing update was added the vanilla game now allowed ordering axes form villages. Vanilla players wanting to a specific axe could now get one likely through more hunting & hidework to get the value. Modded players were already making their own choice of axe, exploring the wilderness for sources of iron, crafting tools for getting ore, making charcoal and so on.
I am overall pleased to see more aspects being added to Unreal world and hope to one day see a vanilla player blacksmithing their own axe far away from a village.
>>>
On the number of users
For the amount of community interest the BAC 3.82 version shows 524 downloads in post #1 of :https://www.unrealworld.fi/forums/index.php?topic=7176.0
Each time the game went through major updates so did BAC with a new thread to the new game version. So the total number of downloads is hard to know. Many BAC users would have downloaded the next version so the figure above is can be viewed as the active users.
>>>
BAC was sized to have lots yet keeping a couple letters free specifically to allow any additions a particular player might want.
The mod community also has a few career mods like bee keeping which some might want and others not.
Some mods introduce being able to train your combat skills through various token systems. While likely of interest to many players it takes a few menu letters to achieve this so wasn't in the BAC. It could potentially be chosen by a player from the free spaces left by the BAC.
>>>
A suggestion was to add separate craft menu for mods to use. Right? Let's make sure I understand the proposed suggestion correctly and then brainstorm as necessary.
So, let's say we'll make a letter O to open a blank make menu, which you can then fill with modded stuff like the current Make menu. And this would be menu that is reserved for mods only. The game craftings would appear in the exisiting Make menu, like currently. Now, if you would then fill this one modders make menu (O) with one big mod it would be..well..full. If there was a few smaller mods that you would like to put there, with custom menu entries or keys even, they would get messed up and tangled together.
If implemented like this it doesn't sound like a plausible long-term solution, or am I not understanding the suggestion?
Correct. That is the current request.
Modders over the year had requested make menu tiers, that is you open make and open a letter than another letter then the 25 recipes for 15,625 possible craft items. Memory recalls an impression on the complexity being an issue on implementing.
The current make menu has ~25x25 = 625 possible entries. By combining many of the popular mods (Rain etc) yes BAC is running close to that. Certain things have been done to save on space like "iron nails" and "iron rivets" being one recipe as the production is very similiar.
There are some mod swap, letter swap methods that are out there as mentioned by Galgana though I've personally never used them.
The modder's crafting single letter was put forward as a lower coding request. It would mean 625 that a modder can use without the "mod collision" that happens when new features are added to vanilla.
"Mod collision" happens when the vanilla game adds crafting to what the modding already had there is some in game disruptions and confusion. An example is the hafting vs BAC's existing mod code. Yes eventually the BAC would be adapted to the new vanilla standard. Until then here are some things that happen:
- BAC included making an axe thus has both an "axe head" and "axe haft"
- BAC "axe heads" don't work with the new vanilla axe fixing. Players get confused.
- BAC "axe haft" doesnt work with new vanilla axe haft so can't fix a broken axe. Players get confused.
- BAC included a chance of a bad axe mounting and recovering a BAC "axe head"
If the vanilla items and mod items are separate then for the above example what is a "BAC axe head" is kept clearly from "Vanilla axe head" and so on.
Further some item creations involve many steps. BAC has "iron nails" that are double used as rivets do save on menu space. Should at some point Saami add nails or rivets the vanilla/mod make split would avoid confusion between whose rivets are needed in recipes. This is intended as a support not a reducing of the vanilla updates.
In time the mods could update assuming the modder is still around in the community.
As another example. [Bowyer] has been added a skill. I actually think that is great. At the time of the last BAC update there was no such skill so the recipes for bow making it has couldn't use it. In time the mod could be changed over to it. I also wouldn't be surprised if there a players confused on which bow string to use as some will be vanilla bow strings and some BAC bow strings.
-
I think this is a good discussion, and I'm glad that the discussion is happening.
Also, just to make it clear; I don't see any offense intended, nor do I intend to do so myself by this comment. Just trying to ponder on a bit more abstract level;
OK, so the underlying problem is that there is a good large mod a lot of player like and use the mod - and then any new update to the vanilla game introduces something which is not compatible with the mod.
What needs to be done to fix that? I see two main alternatives;
1. The mod is updated to make it compatible with the latest version of the game
2. The vanilla game is modified to keep the new version of the game compatible with an old version of a mod
Or, the same worded bit differently;
Oh noes! A mod is not compatible with the latest version of the game! Somebody do something to solve this! Who you are going to call? Ghostbusters? No? Then who can do a bit of extra work to solve the issue?
1. The modding community to the rescue! Mods are by the players, for the players, so both making and updating the mods is something the players can contribute
2. The lead developer Sami! In addition to making all the updated to the vanilla version why doesn't the guy just do some more extra work to keep the game compatible with the mod !?!!
---
Now, this maybe does not come as a surprise to anyone, but in both descriptions the option 1. seems more natural and fitting to me.
And then, in the case of BAC, if the underlying problem is that at the moment Brygun wants to focus on other things and is not actively maintaining the mod - then who should step in to fill the gap? Sami the lead developer? Or someone else from the modding community?
I'd say "the modding community" - like a clear message on the modding forums telling that at the moment the B of BAC does not have time to actively update the mod, so looking for new people to contribute, keeping this beloved large community mod alive and compatible with the new versions of the vanilla game.
---
Again, I'm not claiming that this is the truth to this question. I'm just trying to clarify the way I see the situation, and I have a feeling that Sami's opinion is not so much different. But if you, the players and the modding community, see things differently or wish to point out something obvious I'm missing in my reasoning, I'm happy to hear your voice.
If I understand correctly the points already mentioned, the suggestion has been that a little bit of 2. is wished for, as seen from the player perspective Sami adding just one extra hotkey to the vanilla game should not be very much of extra work, but that little bit by Sami would offer an enormous relief for the modding community, bearing fruit for years to come. And then the reply to that involves the usual "woah, not to fast - let's first consider this carefully to see if adding that one extra hotkey is going to bring about new problems, or if it is going to require so much additional coding by Sami that it waters down the entire argument of "little extra work to reap enormous gains" instead of "the modding community doing the modding"
-
Dedicated hotkey for mods would make sense.
But would that outrule current option to touch up/edit vanilla recipes?
I like that I don’t need to add new menudef to add say wooden mugs or making stakes from boards, just add those in the vanilla diy_glossary.
I would prefer the “easy editing” stay as is.
Also for reading all the recipes at game launch, it’d make testing mods a massive pain. Edit, save mod. Shutdown, start game. Find a need to edit further. Repeat.
No thanks!
-
What needs to be done to fix that? I see two main alternatives;
1. The mod is updated to make it compatible with the latest version of the game
2. The vanilla game is modified to keep the new version of the game compatible with an old version of a mod
The third is what is in this thread.
3. Provide a separate make menu for modders from the vanilla.
What then happens is that when there is an update and the resulting incompatible is the one thing the mod community needs most: Time.
It also lets a mod user decide when to take in a mod update, since they are all manual installs. Thus they can finish a many step build process rather than finding out their mid process resources or tools are useless.
>>>
Example:
A player in the middle of long game in the middle of a long build cycle, like lamellar armor, can still access for that time the mod's build steps while other players can start the vanilla process.
In the case of lamellar armor various steps including the following recipes:
ore scoop, roasted ore, charcoal, smelter, smelted ore, anvil, hammer, ingot, then drill and cords
If any player blacksmithing is started some or all of those will get duplicated in the vanilla. Given the many build steps a player could be anywhere along that process.
>>>>
On what happens to the BAC when I go it was already built in that after 30 days of inactivity a new caretaker may take it over with the same terms. Not only was that planned for there was already a handoff once already to Rudy. I'm currently willing to hand off again at the moment too. The BAC though heavily my work is thought of a community owned item. Much of the work comes from the shoulders of people like Rain, Endive and Bouddia. While their exact recipes had to be changed the principles and concepts they set up are in the DNA of the mod.
-
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:
.Stoney arrowhead. "Stone arrowhead" [effort:0] *CARPENTRY* |0| /1m/ [patch:5]
// migrate old arrowheads
{arrowhead} [remove] [patchwise]
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.
-
After that, I continue along happily with using the mod.
-
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.
-
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:
private void ModManager_KeyDown(object sender, KeyEventArgs e) // Hide/Show extended menus
{
if (e.KeyCode == Keys.Escape)
{
this.Hide();
//MainForm.Show();
//WindowHandling.SetForegroundWindow(DefaultData.URW.MainWindowHandle);
}
else
{
foreach (Keys k in AssignedKeys.Keys)
{
if ((e.KeyCode | e.Modifiers) == k && !PlayerM.IsViewingRecipes && PlayerM.IsViewingWorld)
{
MainForm.GameEventHandler.HotkeyFunctions.RecipeCheck();
string GameKey = AssignedKeys[k][0].Split('-')[1];
string Menu = AssignedKeys[k][0].Split('*')[1];
File.WriteAllText(DefaultData.GameDirectory + Files.DefaultMenudef, AssignedKeys[k][0]); // <---writes selected menu key to menu def then performs macro to access menu
switch (Menu)
{
case "MAKE": // Shift M, +
WindowHandling.PostMessage(RWMain.TargetProcess.MainWindowHandle, WindowHandling.WM_CHAR, '+', IntPtr.Zero);
Thread.Sleep(25);
WindowHandling.PostMessage(RWMain.TargetProcess.MainWindowHandle, WindowHandling.WM_CHAR, GameKey.ToCharArray()[0], IntPtr.Zero);
break;
case "COOKERY": // alt C, s + c
WindowHandling.PostMessage(RWMain.TargetProcess.MainWindowHandle, WindowHandling.WM_CHAR, 's', IntPtr.Zero);
Thread.Sleep(50);
WindowHandling.PostMessage(RWMain.TargetProcess.MainWindowHandle, WindowHandling.WM_CHAR, 'c', IntPtr.Zero);
Thread.Sleep(25);
WindowHandling.PostMessage(RWMain.TargetProcess.MainWindowHandle, WindowHandling.WM_CHAR, GameKey.ToCharArray()[0], IntPtr.Zero);
break;
}
this.Hide();
//MainForm.Show();
//WindowHandling.SetForegroundWindow(DefaultData.URW.MainWindowHandle);
}
}
}// else if ()
}
-
Dedicated hotkey for mods would make sense.
But would that outrule current option to touch up/edit vanilla recipes?
I like that I don’t need to add new menudef to add say wooden mugs or making stakes from boards, just add those in the vanilla diy_glossary.
The most important and really only change Im asking for is a make menu the vanilla recipes updated by the dev never go into. You could edit the vanilla recipes just like now. For large mods changes in the vanilla in the update can cause a series of cascade issues. A lot of time by the caretakers has gone into shuffling things to fit into the 625 slots we have now. When "H" was picked for hafted that impacted a slot of 25 of those.
I'm only asking for a modders safe space.
Saami would go on adding things to the 625 slots as he moves along. It just that those changes wouldn't immediately collide with the large mods.
The mod space would be sitting at its version with no changes until such time as the modder gets to updating it.
Without a safe space it will be an ongoing cycle of immediate complaints and disruptions to those playing the large mods.
The management of the 625 recipes of the mod space is upto the modder. If there is a large modder, like BAC or others, its up to them to manage the mod-625.
Imagine if in the future Saami decides to start on player blacksmithing and adds his version of charcoal as one of the steps. Immediately the vanilla-charcoal isn't the same as mod-charcoal. Recipes people are in the middle of using don't work. To put in the vanilla-charcoal a menu space or menu letter was used creating problems in the shared-625 that doesn't exist if we have a mod-625 vs dev-625. With the split the mod recipes still exist and their version of charcoal is accessible for those in the middle of long tech tree work.
When a player sees an update for their mod is available they have a choice of when to make the transition. Thus a chance to finish any big project like making an iron helm.
Also for reading all the recipes at game launch, it’d make testing mods a massive pain. Edit, save mod. Shutdown, start game. Find a need to edit further. Repeat.
No thanks!
I dont see how that would be necessary. Even now, other than menudef, you can have a game running and edit a recipe then go to the make->item and it loads the menu current in the text file. Nothing I've suggested would change that. Not sure if someone else was saying that or where this came from. You'd don't need to reload the game to check changes in a recipe.
-
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,
Thank you.
I recalled it existed but at time didn't need to use it myself. Couldn't remember its name or maker. Thank you for bringing it up.
-
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.
-
Ah thanks.
I'm not asking for changes to the "B" build but the crafting "M" make due to the overlapping that is now happening as Saami adds crafting creating duplicates to what has been possible in the game for in some cases over 10 years. Craft menu space is needed.
-
Good to hear more discussion and opinions on this matter.
There seem to be some differencies in how people perceive the modifications working in the game world, and from devs point of view it gets a few more extra layers and viewpoints to it.
To pinpoint it; modding code modifies the existing elements, more or less. It can't modify the properties the items don't have, or to add game mechanics that don't exist. For example, items have a name, and it can be modified to anything at all, but naming cat a dog doesn't make it essentially a dog. Nevertheless, lots of things and stuff to do can be created with the modding code.
With the above in mind, one must understand that even with a separate key or limitless mod entry space the player confusion with mod created items may continue happen when new mechanics are introduced. For example, if there are modded hafts or items put together from modded heads and hafts, they aren't working as genuine multi-part hafted items in the game. (I don't know actually how the game might deal with such but maybe the hafts won't wear out, the proper head doesn't drop when the item breaks, and so on.) Confusion and frustration may follow as players who aren't into modding will have to deal with the oddly and wrongly working items. It's not a problem for those who are aware of the modding and it's underlying mechanics, and maybe can even convert items as in Plotinus's example, but with the public mods who get into hands of average players the remedy or regarding information in these cases is best to come quickly.
Surely, a separate modding make menu will make things (also updating) easier and also keep the original and modified entries nicely separate. But it may be that for an average player who's used to create modded item A from, say a new Modders Make menu, they may fail to notice it having appeared as a genuine game feature or item to the original Make menu. So the confusion and game mechanics incompatibility with the modded items is evident to happen to some extent from time to time, even if there was limitless space. But it's ok when it's remembered, understood and addressed clearly to the mod users when necessary.
In any case, separate menu seems to get support from this small bunch of thread participants.
But it really doesn't happen just like this:
.Modders Make Menu. "Make menu" [effort:0] *CODING* %50% /5m/
{Make menu}
;)
-
In any case, separate menu seems to get support from this small bunch of thread participants.
But it really doesn't happen just like this:
.Modders Make Menu. "Make menu" [effort:0] *CODING* %50% /5m/
{Make menu}
You asked for the modding community input.
So we don't matter to you?
Just a "small bunch".
-
Bry, I think you missed the joke in the recipe. 5minutes with %50% skill boost and 0 effort too. I half expected it also to include [phys:stance]
-
Yes, I think a separate space for mods would be quite useful.
When mod functionality gets implemented into the game, mods ought to phase the mod version(s) out, and it would be useful if the mods then contained "translation" recipes for a transition period. Mod maintainers have limited amount of time available, though, so what's desirable might not be what's reasonable at all times.
Mostly it's up to the mod maintainers to adapt to the changes in the game, but a mod space seems like a reasonable game support (when "resources" are available to provide it).
I don't think it would hurt for the developers to look at mods occasionally to get some additional perspective on intended new functionality. Not as "this is how it has to be", but rather to provide aspects they may not have thought of. Also, a proper implementation would not be restricted by the same constraints mods have. However, the developers obviously have to manage their time, and looking at mods may well end up in the "no time for this now" bucket constantly.
-
So we don't matter to you?
Just a "small bunch".
Huh? Honestly, I can't quite see where this comes from. So let's take an another look at what has been said and what has not been said:
In any case, separate menu seems to get support from this small bunch of thread participants.
To me this does not sound derogatory, not at all. When Sami says "this small bunch of thread participants" I read it as saying:
OK, earlier there was a mention that there have been 524 downloads for the mod, so let's assume that as a guideline to estimate the number of users. And then we have 6 members of the modding community participating in this thread. That means we have heard the opinion of 1.2% of the modding community.
[EDIT: while I was writing this we got the 7th voice, PALUs opinion]
Is 1.2% a small bunch? Is six persons a small bunch? Or should that somehow be felt as an insult, a way of saying "your opinion does not matter?" Honestly, sounds a bit off to me. And, the "ouch you hurt my feelings!" is always a tricky path to walk along - if one chooses to do it, then it probably would also be beneficial to start with spelling correctly the name of lead developer. It is only four letters, so shouldn't be that hard to spell, so if one constantly writes it in a wrong way, should that be taken as a sign of ignorance, derogatory gesture of non-mattering? Does not sound very constructive to me, better just focus on the actual facts that have been said, and work on the subject matter itself.
So, what we have then, at the moment:
- a suggestion to add a separate hotkey to bring up only the modded crafting recipes
- roughly 5 members saying that they support the idea
- one member saying that it would not be so very important for them, as they prefer to just update the mod code themselves to adapt to the new versions of UrW
- Sami signaling that he is still open to consider the idea, just saying that to implement it would take some extra work on his part - and that the amount of that extra work is probably a bit more than just a few lines of code.
What we do NOT know:
1. of the 518 mod users who have not commented in this thread, how many of them see that an extra hotkey would solve their problems
2. and how many of them see that the top priority should be just to have the mod actively maintained, so that it would stay compatible with the new versions of UrW
And the way I understand it, Sami mentioning about "small bunch" is a reference to the situation 1. - scientifically speaking, critically thinking, we have no way of knowing if our gallup of 6 people out of 524 gives an accurate representation of the general public mood or not. Not saying that the voice of 6 people does not matter, not insisting that it is not aligned with the majority. Just reminding that given the current evidence we can make an educated guess, not knowing for certain. And there is nothing wrong with it - in any case life is mostly about making decisions based on uncertain evidence.
Lastly, to me it still looks like that even in the case Sami added that extra hotkey to the vanilla game, it would not do very much to solve the situation 2, which probably needs to be addressed separately - at least if in the modding community there are people who care enough about large mods like BAC to maintain the mods. But if it so happens that there is no active modder to maintain a mod, then that just is the way things are at the moment? But, personally I see that mods matter, and modders matter, and modders matter to other modders, so it would seem rather natural that this leads to mods being maintained and updated to stay aligned with the new versions of the game.
-
A tangent regarding the lead developer's name from someone who doesn't know Finnish but has a slight idea of how Finnish works:
- The name is Sami, and I would "translate" it into English spelling as "Sammi".
- The Saami is a people related to the Finns. They're spread, as a people, over the northern parts of Norway, Sweden, and Finland. They also used to live on the northern part of the Kola peninsula, but I don't know if they've been exterminated, forcibly relocated, or remnants still remain there. Their name is pronounced with a long "a".
-
Also, just to be sure, a few more word of clarification on my side:
I didn't mean to say that adding a new key to bring up modded recipes would not help at all with maintaining and keeping the mods up to date with new version of UrW.
What I was thinking was a scenario like this:
1. Sami adds the new hotkey
2. But somehow it happens that no-one from the modding community updates BAC recipes
Then, the way I see it, the underlying root problem would remain unsolved - the extra hotkey probably would make it easier to access all the recipes in the mod, but the confusion with vanilla items and modded items, and vanilla recipes and modded recipes would still continue to exists.
But, I do see the point represented by PALU and others; having that extra hotkey would help in the transition phase, when a new UrW version introduces new mechanics, and the mod needs some time to adapt, and a clean way to access "compatibility recipes" to transform old modded items to corresponding new vanilla items. And that is something I fully support, and to me this sounds like a good argument.
---
Also, personally I like the modding approach. And in my opinion Sami has been maintaining a fine balance between "an artistic indie coder following his inner vision" and "listening to the player suggestions and wishes" - not locking up in the ivory tower, nor getting lost in the endless swamp of "design by committee". I see my role as helping Sami to develop the game which fulfills his inner vision.
And, at the same time I see that some players wish for a fully moddable game, which would have the modding in-built into the core structures of the game engine. I find that an interesting idea, but I do understand that it would be an another game, not UrW but something different. Now, as some of you might already guess - I suggest that those interested in exploring the possibility of a fully moddable survival game could take a look at the Ancient Savo project and its modding system. (not wanting to hijack this thread, just my contribution to the theme of "yes, Enormous Elk does care about modders, modding matters")
-
Here comes a brief catch-up with the replies I haven't yet responded. The discussion may continue and possible changes are being pondered accordingly. Amid all the other issues at hand, that is.
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.
Increasing the possible number of variants and for wider range of tiles could indeed enhance the experience regardless of it being thought of being a modding feature. In the future we're evidently need to undergo a greater graphics update, once again, which will require serious rewrite of the graphics engine. More variants possibility might get considered then, but for now it is a low priority. Plus, having started with mere ASCII graphics the game has always been developed from the content over graphics perspective. And it shows. ;)
(And as a curiosity the most frequently popping up graphics suggestion over the past decade has been probably to go for 3D.)
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.
I believe you're quite right with that. Hence the careful considerations will save both my and modders time.
Dedicated hotkey for mods would make sense.
But would that outrule current option to touch up/edit vanilla recipes?
I like that I don’t need to add new menudef to add say wooden mugs or making stakes from boards, just add those in the vanilla diy_glossary.
I would prefer the “easy editing” stay as is.
Easy and quick editing was indeed one of the key elements I had in mind when modding was introduced. Just drop in a snippet of modding code and it's in effect. Or to adjust the recipe if you'd personally prefer it the other way.
With dedicated mods make menu there would be indeed separation between the original recipes and modded recipes, both in menu level and editable text files level. Of course the original diy_* etc. files would still remain editable, and new file snippets could be added, and the edits and additions for those would appear in the original make menu. Mod recipes would appear in mods make menu. So with an example of making wooden stakes you could still quickly add your own "wooden stakes from boards" diy_* snippet to the original recipes and it would appear in the original Make menu.
Or you could also make your own lumber (or whatever you want to name it) category as a mod diy_* and it would appear there in the mod make menu.
Also for reading all the recipes at game launch, it’d make testing mods a massive pain. Edit, save mod. Shutdown, start game. Find a need to edit further. Repeat.
Hmm. I'm not sure if I managed to describe it correctly. I'll try again.
Let's assume you're creating your own mod, and there are no other mods installed.
You would not get any extra hassle, the game wouldn't notify you of any modding conflicts.
Let's say your own mod would have recipes for four items: Round item, square item, long item and short item.
Excellent. Now let's imagine Player X likes your mod and installs it.
After a while Player X decides to create his own mod for crafting long item, as he prefers it to be done the other way. Player X is very happy with the rest of the items in your mod and doesn't want to touch them.
Now if Player X would install his own mod on top of your mod there would be two mods with a recipe for long item.
In this case the game would check and somehow confirm if the player would like to use your recipe or Player X's recipe for crafting long item.
Something like this needs to be done anyway if the problem now is that all the space and available entries get eaten up and reserved. Otherwise mods that would modify or add the same recipes to any extent can't co-exist. Yes, they can't co-exist currently either, and players need to shuffle with loaders, manual editing and stuff. But to invest time to add a separate mod make menu which would exclude different mods to co-exists once it's (yet again) filled all up would be waste of (my) time from my perspective.
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.
Yeah, after years or decades of roaming the unreal world it's truly so in my opinion too that modded stuff can answer to "hmm, what should I do next" feelings, or to the classical "end-game" boredom. The game is indeed very much what you make of it, even though I would phrase the rest of sentence a differently. And well, as far as I am concerned it's very much confirmed that the game has enough content to support long gamespan. Which of course is debatable and varies between the players and playstyle. Heh, and with a such freedom allowing beast of like UrW the thing is that there's never enough content for everyone, no matter how much is added. (This a fact pretty much all the devs have to live with.)
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.
We do have suggestions forum, where suggestions can be posted, and we are constantly - and I truly mean constantly - being asked, requested, suggested and sometimes plain commanded to do this and that.
With good manners suggestions are not unreasonable. What is unreasonable is to expect all of them to happen.
However, for years already we've passed the critical mass point of suggestion flood and still fortunately remain a rare example of developers actually (still) communicating with the players and taking their thoughts into consideration.
If the probable modders are counted in hundreds the players are nowadays counted in tens of thousands.
Speaking of game limits, I can't resist of inventing a developer's aphorism/koan of the day:
Does Tetris game have a limit of not featuring table tennis mode?
I don't think it would hurt for the developers to look at mods occasionally to get some additional perspective on intended new functionality. Not as "this is how it has to be", but rather to provide aspects they may not have thought of. Also, a proper implementation would not be restricted by the same constraints mods have. However, the developers obviously have to manage their time, and looking at mods may well end up in the "no time for this now" bucket constantly.
I think we have quite good understanding of the most wanted features from the suggestions sections already, where also new things to craft are also popping up. I also get the picture that things that are on the development roadmap are being modded also. For us, to stay on track, it's the suggestions section where we expect the new ideas and features to be presented and there they remain nicely and easily accessible when looking for new features consider. And for most of the suggestions I usually get "yes, yes, that would be nice, in time, hopefully." feeling ;) My personal to-do list actually doesn't go shorter but longer with every version release. This may sound odd, but it's a fact.