Show Posts

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


Messages - Galgana

Pages: [1] 2 3 ... 10
1
Gameplay questions / FYI on modding BIY files
« on: October 21, 2025, 12:28:11 AM »
Unlike DIY recipes (where a single "base item" can be created under multiple entries and with various modifiable properties), a maximum of one recipe entry per .terrain tile. (which includes man-made structures as well as natural terrain features) is readable by the game when it comes to biy_*.txt files.
For reference, here is the vanilla kota wall recipe:
Code: [Select]
.North-west corner of a kota. [effort:2]  *BUILDING*  [GFX_X:5] [GFX_Y:0]   [assist:3]  |+1|  /15/   %10% 
.Northern wall of a kota. [effort:2]      *BUILDING*  [GFX_X:6] [GFX_Y:0]   [assist:3]  |+1|
.North-east corner of a kota. [effort:2]  *BUILDING* [GFX_X:7] [GFX_Y:0] [assist:3]  |+1|
.Western wall of a kota. [effort:2]   *BUILDING* [GFX_X:5] [GFX_Y:1] [assist:3]  |+1|
.Inside of a kota. [effort:2]   *BUILDING* [GFX_X:6] [GFX_Y:1] [assist:3]  |+1|
.Eastern wall of a kota. [effort:2]   *BUILDING* [GFX_X:7] [GFX_Y:1] [assist:3]  |+1|
.South-west corner of a kota. [effort:2]  *BUILDING* [GFX_X:5] [GFX_Y:2] [assist:3]  |+1|
.Southern wall of a kota. [effort:2]   *BUILDING* [GFX_X:6] [GFX_Y:2] [assist:3]  |+1|
.South-east corner of a kota. [effort:2]  *BUILDING* [GFX_X:7] [GFX_Y:2] [assist:3]  |+1|
.Kota doorway. -D- [effort:2] *BUILDING* [GFX_X:9] [GFX_Y:1]
{Cover for kota} [remove]
{Slender trunk}  [remove] [ground]

BTW for the sake of convenience, multiple recipe headers can be stacked in either DIY or BIY files when it is desirable for the outputs to share the exact same inputs.

The required item {Cover for kota} is a pre-defined material that accepts a skin-category item (which normally is a finished tanned hide of either fur or leather) weighing more than 7.0 pounds (see this discussion thread on steam for how this number was obtained).
The game's native behavior for returning inputs from map-generated kota walls upon deconstruction will yield 1 slender trunk and 1 ragged reindeer fur (which happens to weigh 10 pounds).

If you're using mods that overwrite entries from biy_glossary.txt, you're likely to encounter issues due to the game not recognizing modded inputs for whatever reason.

The simple fix: disable modded BIY additions by renaming the BIY text file to something else that doesn't start with biy_ when you're not actively building.
(Depending on whose BAC fork it came from, your game directory might already have them as boff_biy_BAC or bin_biy_BAC)

Here is what BAC lists for the required items under biy_BAC_kota_hideworking.txt or biy_BAC_hideworking.txt (again, depending on which version you've downloaded):
Code: [Select]
{Slender trunk}  [remove] [ground]
{* cover} [remove] 'Kota cover'

BAC's approach to DIY-ing kota covers under its hideworking module (modded crafting submenu: Hide and Bone) is to utilize a minimum weight of 8 pounds (whether from a single source or multiple pieces). This accomplishes 3 things:
  • Rather than having to commit an entire large hide to building a single kota section, the player is free to use the remainder of the hide in other projects;
  • Similar to the [nominlen] tag for {Tying equipment} with =length= requirements, multiple pieces of the required material can be used to craft a BAC cover;
  • Since these BAC cover recipes have clothing as a base item, the outputs should inherit armor properties (namely the warmth value) from the original skin(s) (or an average of these inputs).

But when I tried to deconstruct the kota, the wall only gave me 1 generic slender tree trunk, instead of 1 slender tree trunk and 1 kota cover/fur.

To confirm, I save-scummed another ongoing character, built a kota and then deconstructed the wall. It correctly gave me 1 slender tree trunk and 1 kota cover (used BAC, so might be different in Vanilla?).
In this case, the main problem comes down to the required item string. It uses an asterisk as a wildcard character, which can be a boon for crafting but ends up being indecipherable in the situation of deconstructing map-generated terrain structures.

While the game memory does retain building inputs from the player, it can't retrieve anything to fill in the modded asterisk blank.

2
Modding / Re: A Query on Realism in Modding
« on: September 10, 2025, 06:25:58 PM »
Well, it's a single-player sandbox game. You can be as cheesy-cheatery versus hardcore realist versus magically-inclined as whatever mood fits the session you're playing.

We all have different approaches and play styles for our characters, and it's worth sharing the things that have in some way improved how we experience the UnReal World. There's a niche for just about anything imaginable.

Chances are, somebody else may find XYZ crafting recipes useful or such-and-such graphical edits aesthetically pleasing. And this hypothetical other person might even become inspired to do their own take - which is completely fine.
That said, certain licenses can put restrictions on the redistribution of the results of recursive modding exercises. For the sake of the community, one ought to honor the permissions provided in the documentation. (And when in doubt, please do ask :) )

3
The legacy method (NOT prefixed with mod_) for adding recipes to new submenus is broken. This is contrary to the changelog for version 3.86:
Quote
The existing method of adding modded items to the original [M]ake menu with diy_*.txt and menudef_*.txt files still works the same as always, so there are no changes required for your mods unless you want to separate them from the original [M]ake menu.

These are the contents of files I added for testing:

menudef_new.txt
Code: [Select]
.new. -E- *MAKE*
diy_new.txt
Code: [Select]
[SUBMENU_START:new]

.Rock. /1/
{[NEARBY_TILE:Ground]} 'on the ground'

[SUBMENU_END:new]

When I select a new submenu, nothing happens. It is recorded in the message log that I have selected that handcraft submenu, but the submenu itself does not appear.
Other things worth noting:
  • DIY additions to the base game's pre-existing submenus display as normal.
  • Adding mod_ prefix to the above files does work as intended.
  • Users of the BAC modpack (updated for version 3.86) have reported that new cookery submenus do not show up, although I have not observed this happening in my own non-BAC modlist where custom cookery submenus from menudef_*.txtcookery_*.txt recipes display as normal.

4
Gameplay questions / Re: Weapon Durability
« on: March 23, 2025, 07:21:33 AM »
Ever since URW version 3.83 introduced tool degradation to crafting, it is no longer enough to keep your equipment pristine through only the setting [WEAPON_DAMAGE:NO] in urw_ini.txt

For DIY recipes provided in diy_glossary.txt, you can manually replace all instances of [wearpct:num][nowear]

BUT tool degradation will still occur when performing skill menu actions (example: felling trees through Timbercraft).
That's just the UnReality of what's been hardcoded.

5
The simple answer is that riverpig lacks any properties related to plant products in the flora data located in flora_newherbs.txt
But according to brian.shapiro's flora suggestions thread on the old forum, there ought to be roots at a minimum:
Quote
"The Sami were digging for the roots that were eaten with pleasure (Nensén p. 415). Slappakråsse (Grundström 1948:393) or slabbaråsse (Grundström 1948:369), yellow and white water lilies {Nuphar lutea and Nymphaea alba). The rhizomes of these perennial water plants have a strong, bitter taste. They contain toxic alkaloids and need to be processed and detoxified prior to eating (Airaksinen et al. 1986:280, 284, 287, 291). The rhizomes were used as famine food in northern Europe (Airaksinen et al. 1986:279; Kjellman 1882; Källman 1997:122-123; Svanberg 1998:234). Water lilies were eaten by native peoples in northeastern North America (Källman 1 997: 1225), hoewver they were primarily used for medicinal purposes to treat ulcers (Turner et al. 1990:235). There is no information on the Sami use of slappakråsse."

I think it would be appropriate for these lines to be added to .Riverpig. and .Water lily.
Code: [Select]
[ROOT_SIZE:M]
[ROOT_QUANTITY:1]
[ROOT_USE:cooked]
[REMOVE_BOILED:poisonous]

6
I noticed that when my character is facing certain directions on the local terrain zoom-in map, a young spruce tile becomes doubled.
And I haven't consumed any noaidi mushrooms recently :)

This happened when my settings in urw_ini.txt had [SCALE_QUALITY:1] or [SCALE_QUALITY:2]
I have NOT encountered similar graphical issues with [SCALE_QUALITY:0]

7
I was exploring a mountain terrain that has a mix of pine mire and open mire surrounding it.
On the mountain's south side I noticed black lines appearing under the water tiles (examining the water confirmed they are plain water rather than being springs) wherever there was a south elevation border.

These lines seem to persist at every
  • zoom level
  • window size
  • resolution (when logical resize setting = no)
  • scale quality setting

8
When I entered a Reemi village, I saw there was both a rock and a mace at a ground tile.
When I picked up the mace, it gained the (unpaid) inventory tag. Then I talked to a nearby inhabitant to enter barter mode, which confirmed I owed debt for the mace.

I think instead of a mace, there should have been either a stone or another rock for outdoor ground clutter.

9
I thought “Kaumo” were from Savo and Karelian were from “Reemi”.
(I was born Tavastian,  at “Koivula” and I’m still not happy about calling vihta a “vasta” in-game… j/k
Also the cultural skill points don’t make justice for the fishing and trapping heritage.

:P derp! My mistake.

Here's a list of UnReal regions corresponding to IRL for anyone interested (I copied it somewhere from Erkka):
  • Kaumo = Kainuu
  • Kiesse = Savo
  • Reemi = Karelia
  • Driik = Turku
  • Sartola = Pohjanmaa
  • Koivula = Häme
  • Northern = Sápmi

10
For an assignment in secondary school, I wrote a thousand-word poem about the 2012 Wifecarrying World Championship in a style inspired by the Kalevala (or at least English translations thereof).

And some descriptions based on UnReal nature have also made their way into personal projects.

The main character in my most recent writing thing is partly descended from Karelian Finns (because Kaumo = cool 8)). Some ideas concerning his development arise from reading up on Orthodox icon lore and the vitae of saints, although this guy behaves in ways very far from saintly haha.

11
Development News / Re: Version 3.85 beta released
« on: October 31, 2024, 01:05:10 AM »
I have a mod with recipes that 1) reduce the weight of logs and slender trunks for the sake of easier transportation 2) revert these items to their normal weight.

Of course, these products remain generic in the current beta. But once the inheritance of tree species does become fully implemented, I wonder what support the modding syntax will have for specifying the tile graphic index?
I was thinking about using [name] to retain species identity in my modded crafts, but the result will be less than ideal if I'm unable to keep the products visually uniform with unmodded stacks.

12
Not bugs / [not a bug] tag required to inherit [name]
« on: October 31, 2024, 12:56:02 AM »
I wanted to test how to handle modding with tree species, so I had my character fell a spruce tree.
But then I ran into a problem:
Code: [Select]
[SUBMENU_START:utility article]

.Wooden effigy. "Branch" *TIMBERCRAFT* /1/ [effort:0] [noquality]
//{Tree trunk} [name:%s effigy] [naming:first word]
//{Tree trunk} [name:%s effigy] [naming:last word]
//{Tree trunk} [name:%s effigy] [naming:original]
{Tree trunk} [remove] [name:%s effigy] [naming:first word]

[SUBMENU_END:utility article]
The lines I commented out were ineffective since they produced only unlabeled wooden effigys.
The last line successfully produced a spruce effigy.

Depleting the [name] source item isn't always convenient (though that'll depend on whatever is being crafted).
Will it be possible for [name] strings to be applied without the [remove] tag?

And on the side, can we get stacks of modded items ending in "-y" corrected to "-ies"?

13
Solved'n'fixed bug reports / Re: Bug in LoydettyTarvike() function
« on: September 15, 2024, 12:08:05 AM »
LoydettyTarvike errors are triggered by recipes that are missing components for certain base objects which have been hard-coded with detachable parts.
Ah, okay, so this happens because the item to be crafted is a "Fishing rod" and nowadays the fishing rod needs a hook, which is associated with the item properties.
As the game fails to find the hook in used the materials/parts, it reports about the failure.

Instead of "Fishing rod" for the base item, "Lippo" might be a better fit.

14
Modding / Re: Old carpentry crafting
« on: August 25, 2024, 01:17:09 AM »
Any DIY crafting recipes that use *CARPENTRY* skill in its header will populate the Carpentry skill menu.
Besides the Make Menu, there are 2 other methods for accessing Carpentry recipes:
  • select Carpentry on the skills screen
  • key combo Alt+Y (or a custom hotkey in case you may have edited the file ini_skills.txt under the game's main directory)

Note that BAC adds a lot of items, which may not all fit within the crafting submenu's 25-keys cap.
If the weapons you wish to craft aren't available under Skills → Carpentry, try checking the weapons crafting submenu.
And if you can't find the weapons submenu, open any menudef text files in your game directory to get some idea of the submenu names under which modded content has been organized. These names ought to correspond to the file names used in BAC's DIY text files.

15
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.)

Pages: [1] 2 3 ... 10