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 ... 9
1
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.)

2
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

3
In these cases the ground has been created in the water for the tree to stand on
Interesting... I suppose that must be the underlying mechanism for the Netherlands-style land reclamation exploit in this old thread! ;D
It's a fun side-effect which several players would sorely mourn the loss of.

If considered necessary this could be tidied up so that the trees would appear straight out from the water, with no ground showing at all.
Now I'm wondering whether a randomly-placed tree may possibly overwrite a spring tile in the current iteration of the terrain generator.
This hypothetical situation could be attributed to bad RNG luck. But I think that accidentally erasing the chance to discover a water source is more saddening than if a player simply failed to notice water tiles which happen to be concealed by the trees or flora growing on top.

4
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.

5
Bug reports / [Fixed - 3.83][3.84] wp-javelin = it-brkhaft
« on: May 03, 2024, 08:00:02 AM »
The hafting update had overwritten the javelin sprite.

I'm attaching the old sprite in case other players wish to revert the change.

6
While exploring open mire terrain, I noticed that marshland tiles in the middle of watery areas did not have moss groundcover when the terrain generated a tree on top. But then I saw some tree-bearing tiles next to water did occasionally have moss.

I'm attaching a set of screenshots taken at 2 different open mire terrains with pine mire on the border.
Non-mossy tiles are highlighted in yellow.

I was wondering whether the absence of moss is an intended effect of the zoom-in map's terrain generation.
It raises an interesting question about the ecological mechanism by which a young spruce, specifically, uses to inhibit moss if such a tree should happen to be standing in waterlogged soil. ;)

7
Gameplay questions / Re: Retting and Nettle
« on: March 12, 2024, 05:19:20 AM »
For players who aren't engaging in agriculture to grow fibre crops (or don't plan on stealing those crops from settlements), harvesting a stockpile of raw nettle plants is a viable strategy that guarantees you'll have the supplies to craft yarn if the need should arise during wintertime (when retting becomes impossible because of icy cold water).

8
Gameplay questions / Re: Travel time raft vs. walking?
« on: December 29, 2023, 01:37:46 AM »
But it seems like they both can only hold 40 stacks of different items. I found out the hard way: after raiding a Njerp village and trying to load 100 individual pieces of clothing onto my raft.
If only those njerps had also owned livestock for you to steal... Pack animals have a stack cap of 20.
But there's also a cap for how many NPCs can occupy the same tile, which can be a problem when you're switching between wilderness/local zoom maps with a long train of leashed animals in tow.

9
Solved'n'fixed bug reports / Re: [3.82] No more fine/superior blunt arrows
« on: December 17, 2023, 03:01:56 AM »
For the sake of comparison, this is the pre-v3.80 recipe:
Code: [Select]
.Blunt arrow. [effort:1] [phys:hands,one-armed]  *CARPENTRY*       /45/    [patch:5]
{Branch}      [remove] [patchwise] [noquality]
{Feather} (3) [remove] [patchwise] [noquality]
{Yarn}        =1=    [remove] [patchwise]
{Knife}
And here's the recipe after the arrowheads update:
Code: [Select]
.Blunt arrow. [effort:1] [phys:hands,one-armed]  *CARPENTRY*   %15% |0]  /45/    [patch:5]
{Slender trunk} [remove]
{Knife} <Small knife>

The main difference is the lack of [noquality] tag, but this is offset by a +15% bonus to crafting quality.
Of course, you may add the tag to the diy_glossary.txt file in your game directory.

Now I've noticed there's an error in the recipe header: |0] (intended to be a 0 skill-up bonus but it's not properly enclosed in pipes)

10
Gameplay questions / Re: Sauna instructions and usage
« on: December 16, 2023, 10:31:30 PM »
At minimum, the sauna mechanic requires:

sauna stove; an ordinary fireplace isn't adequate for the purpose
  • Most villages will have a sauna building with the stove, a tub to hold water, and a bench (this piece of furniture is just there for immersion afaik)
  • If you wish to have your own stove, you must 1) have a fully constructed wooden building with the walls and floors done; 2) gather 40 stones + 15 rocks to construct the stove.
    A sauna building may also function as a smokehouse, or a small starter home before you acquire the materials for a bigger living space.
fuel to heat the stove for several hours: a good steam requires about 50 pounds of fuel (equivalent to 1 slender tree trunk)

water for steam
  • Pick up a container (any size will do)
  • Stand next to a water source and open the inventory
  • Use the [a] apply key and select the container you wish to fill
  • Stand next to the sauna stove and open the inventory
  • Use the [a] apply key and select the container with water
  • The message log will inform you about the status of the stove's steam; you'll also see the screen flash white and hear sound effects of water being thrown on the heated sauna stove

In general terms for the game's setting, when the weather is freezing a sauna bath becomes the main method of maintaining hygiene. Although hygiene as a system isn't modeled in the game, using the sauna gives a boost to the player's health in terms of wound/illness recovery rate. (For symptoms of poisoning, you're basically sweating out the toxins.)

Applying a vasta will buff the health benefits, so it's a good idea to stock up on birch twigs when they're in season during the summer.

Since the game performs checks to wound status once a day in the morning, a daily sauna regime could help when you require it.

11
You can modify the skill activation hotkeys in the file ini_skills.txt under the game directory.

Simply copy these lines and overwrite to switch the keys for trapping vs tracking
Code: [Select]
.TRACKING. [def:2] [kie:3] [kau:4] [koi:3] [isl:1] [dri:0] [owl:4] [kui:3] [sea:3] [vag:4] [for:1]
[ATTRIBS:eye eye hrg smt]
[KEY:r]

.TRAPPING. [def:1] [kie:2] [kau:2] [ree:3] [koi:2] [sar:2] [dri:2] [kui:2] [sea:0] [vag:2]
[ATTRIBS:dex tch int]
[KEY:t]

Voila! Trapping key becomes consistently [T]

12
With permission JP_finn's bait making, using smaller pieces added. While doing this discovered adding regular build items to the cookery menu. Moved some things over like Privateer's fish cuts, making JP_finn's hot smoker and the kebab stick making from the Nerjpez cooking (from another community member). These are also easier to find as the 2 builds are now in the same general menus where they get used.

Those moves freed up some menu space which is an important part of managing such a large mode.

I'm having doubts as to whether crafts under cookery submenus inherit any properties from "base item" in the recipe header.
Will I have to worry about tools suddenly going stale and spoiling if I don't add a line for [SPOILAGE_DAYS:0]? (That was a coding goof in my initial release of sledwagon reborn when loads are converted to fish, but cookery submenu products receive a spoilage value by default unless specified otherwise.)

Moving DIY recipes to cookery also has an unintended consequence where, for example, .Clean fish. produces fish cuts that aren't accepted as {Raw fish}; instead, they're treated as cooked foods. And I'm assuming the same applies to the baits, which probably reduces their efficacy with animals that prefer eating raw ingredient subtypes.

13
Suggestions / Encyclopedia entry: Shutter
« on: December 11, 2023, 04:09:11 AM »
I think the shutter is deserving of a tooltip as a way to put new players at ease when they notice a construction project appears to be going awry.

And since we haven't got the option yet to shut the shutters, it also would be a great opportunity to clarify whether a shutter has any impact on a building's heat insulation or weatherproofness.

Code: [Select]
.SHUTTER.WALL WITH A SHUTTER.

The shutter is a window feature set into a wooden wall. It provides a view of what lies beyond the other side of the wall. In addition, thrown weapons may pass through the opening.

A shutter under construction will dynamically align with adjacent completed walls and interior flooring once this tile is fully built.

14
Wow, these UnReal fish must surely have thick skulls if they can bump through ice like that. :o

If splashes don't fit the situation, then maybe a bubble graphic replacer would do.

15
Modding / Re: Fat keyword don't work?
« on: November 19, 2023, 09:05:32 PM »
Two problems:
  • Unlike DIY and BIY files, cookery files don't do anything with double quotemarks in the recipe header.
    And, unless defined otherwise, cookery end products inherit nutrition properties from the inputs that use cooking tags:
    • [roast]
    • [boil]
    • [bake]
    • [ember-roast]
  • Rather than being a pre-defined base item, fats and other butchery products are generated on the fly based on the carcass. This prevents cuts of meat, fat, bones and horns from being referenced as the base item in DIY recipe headers (and therefore you can't directly use DIY-crafted pseudo-fats in cookery recipes that call for {Fat} inputs).
Another thing worth mentioning: the display tag [TILEGFX:] makes using :148: in recipe headers obsolete.
Numbers enclosed in colonmarks specify an item's spritesheet index, but for URW version 3.30+ this is no longer needed since sprites are managed as separate files.

Possible work-around with wildcard and renaming:
[/list][/list]
Code: [Select]
.Extract oil from grains.    *COOKERY* [effort:2] [phys:arms,hands] /15/ [noquality]
{* grains}    #4#   [remove] [boil] [name:%s oil fat]

.Butter fat.    *COOKERY* /30/ %20%

.Fried eggs.    *COOKERY* /3/  \5\   %20%
{* fat}    #0.1# 'fat for frying' [remove] [roast]

Pages: [1] 2 3 ... 9
anything