See likes

See likes given/taken


Posts you liked

Pages: 1 ... 32 33 [34]
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
Add springwater to starting scenario maps involving homesteads and camps I think generating guaranteed springs for these start-up scenarios would contribute to immersive design:
  • Lonely settler
  • Not all who wander are lost
  • Runaway slave
  • Abandoned camp
May 04, 2024, 08:37:27 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  
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.


>>>


Quote from: Sami on May 03, 2024, 01:01:46 PM
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.
May 05, 2024, 11:20:04 PM 		1
Re: Make Menu only for Modded items = saving BAC and other large mods 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"
May 06, 2024, 10:30:34 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]
// 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.
May 07, 2024, 06:53:42 AM 		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
        {
            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 ()
        }
May 08, 2024, 06:10:37 AM 		1
Re: Make Menu only for Modded items = saving BAC and other large mods 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]
May 11, 2024, 01:40:56 AM 		1
Re: Make Menu only for Modded items = saving BAC and other large mods 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.
May 11, 2024, 08:58:05 AM 		1
Re: Make Menu only for Modded items = saving BAC and other large mods
Quote from: Brygun on May 10, 2024, 09:34:51 PM

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:


Quote from: Sami on May 10, 2024, 11:02:02 AM

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.
May 11, 2024, 09:06:38 AM 		1
Back to Top