Recent Posts

1

Suggestions / Re: Make Menu only for Modded items = saving BAC and other large mods

« Last post by Sami on Today at 12:31:51 PM »

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.

2

Bug reports / Re: [3.84] open mire tiles under tree lack mossy groundcover

« Last post by Sami on Today at 11:35:03 AM »

It's just so that spruces may generated to shallow water locations.
In these cases the ground has been created in the water for the tree to stand on, but as there is no moss in the water it doesn't appear as a groundcover for these trees.
The locations of the trees standing just next to the water - with no groundcover - have been also water initially.
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.

3

Bug reports / Re: [3.83][3.84] wp-javelin = it-brkhaft

« Last post by Sami on Today at 11:24:36 AM »

Indeed. Fixed now.
(It seems OS X version carries the proper tile, for Win and Linux it was the wrong one.)

4

Suggestions / Re: Make Menu only for Modded items = saving BAC and other large mods

« Last post by Galgana on May 03, 2024, 10:41:12 PM »

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

Development News / Version 3.84 (stable) released

« Last post by Sami on May 03, 2024, 04:55:32 PM »

Version 3.84 (stable) is now released and live for all the supported operating systems; Windows, Linux and OS X.

This version continues the ongoing transition to make all the crafting tasks pausable, features a good deal of related crafting requirement changes, adds BOWYER skill, introduces springs as a new water source and naturally offers a fistful of bugfixes too.

In the midst of big changes in regards to pausable crafting we hope for the bugs to be scarcer than average adventurer's nutrition levels.
And whatever is encountered we do our best to maintain a swift update cycle to overcome the issues as early on as possible.

Here's the changelog, once more:

Version 3.84 (stable) changelog

** Saved characters from version 3.80-> are compatible with this version. **

- added: BOWYER skill

The bowyer skill is the ability and knowledge to make bows. Success in the skill determines the quality of the bows crafted. For migrated characters this skill is created upon the first load in this version.
Needless to say, the available craftable bows now call for BOWYER skill in their crafting.

- added: craftable Longbow

You can craft a longbow from [M]ake menu under "Weapons" category.

- added: pausable weapon crafting

Crafting of the items in [M]ake -> "Weapons" category are now pausable tasks allowing you to have breaks and continue at will later on. These weapons are stone-axe, stone knife, club, javelin, spruce quick-bow, shortbow, longbow and bowstring.
To continue paused weapon crafting use the same crafting option again standing beside the said partially finished item. Like the other partially crafted items these will remain on the ground and can be picked up only after they are finished. They are rendered with a different tint and described as "partially crafted", "half-crafted", "largely crafted" etc. when looking at them.

- changed: crafting times and requirements of certain weapons

Now that the weapon crafting is pausable the production times of certain weapons have been increased to more reasonable levels. There are also minor changes in some material or tool requirements.
The changes are as follows, but bear in mind that these are the average set values and poor tools and/or skills may very well double the actual production times.

* Stone-axe

Stone-axe gets the greatest time increase in the production time as on average it now takes 50 hours to make one. That's a lot, but it really is a slow process to get the stone blade knapped and grinded out to shape that is efficient for felling trees.
Thus, stone-axe now becomes a survival option which you won't take up too lightly, but only in extreme need. Crafting a stone-axe now also needs another stone for final sharpening and polishing. Also, the previous requirement for rope has been replaced with strong cordage requirement. This means you can also use for example spruce withes for securing the head in place in the handle.

* Stone knife

It now takes 5 hours on average to make and also requires a stone for final sharpening.

* Javelin

It now takes 2 hour on average to make.

* Shortbow

It now takes 12 hours on average to make. The time increase is signficant compared to the earlier, and only a skilled bowyer with quality tools may manage to craft a shortbow in one day. With mediocre skills and tools it's a process of several work days.

* Longbow

It takes 18 hours on average to make. Thus, crafting a longbow is a process of several work days even for a skilled bowyer.

* Bowstring

It now takes 2 hours on average to make a bowstring from strands of yarn, and 30 minutes on average from a ready-made cord. When using a ready-made cord it often needs to be thinned down to suitable thickness so it's not just tying of the knots.

- added: BOWSTRING game encyclopedia (F1) entry

- updated: SHORTBOW and LONGBOW game encyclopedia (F1) entries

- added: pausable haft crafting

Crafting of the spear, axe and shovel hafts are now pausable tasks.

- added: pausable item trap crafting and loop snare batch production

Crafting of the paw-board fox trap and loop snare are now pausable tasks. There are also some changes as follows;

* Paw-board

Crafting time has been increased to three hours.

* Loop snare

Loop snares can be made in batches of up to ten at a time, and it takes 20 minutes on average to craft one.

- added: pausable lumber items crafting

Crafting of the wooden stakes, staves and wood slats are now pausable tasks. There are also some changes as follows;

* Wood slat

Crafting time for a batch of 20 slats has been increased to 200 minutes.

* Wooden stake

Wooden stakes are made in sets of 5 pieces from one slender tree trunk. Previously it was 8 pieces from one trunk.

* Staff

When crafting staves one slender tree trunk can yield 3 proper straight staves. Previously it was one trunk for one staff.

- added: pausable utility article crafting for some items in the category

Crafting of the wooden shovel, birch-bark box and birch-bark basket are now pausable tasks. There are also some changes as follows;

* Wooden shovel

It is now made from a board instead of a wooden block. The crafting time has been incresed to 8 hours.

- added: springs

Springs are water sources bringing groundwater to the surface. They can be found in the terrain on zoomed-in maps at varying environments in size of one to three map tiles.
Springs do remain unfrozen even in the winter which makes them very useful water sources. A spring found in the wilderness may provide a great spot for a homestead for those who like to live in the forest further away from the lakes or rivers.
From now on the village water supply ponds are also springs. As they don't freeze they are easier to maintain and spot even in the winter.
MIGRATION NOTICE: Water supply ponds in the villages you have visited in the previous version will automatically turn into springs in this version.

- added: "behind your back" reference to asking for NPC whereabouts

When asking the whereabouts of an NPC who is close by but not seen by the player character, the people will now point out that the target NPC is "...over there, just behind your back.".

- changed: pushing allowed to locations not visible to the player character

You can now [p]ush items around regardless of the location being visible or not. This helps to maintain character's daily life also in the pitch dark low visibility conditions.

- fixed: pausable crafts in process occasionally disappearing when finishing crafting something else beside them

- fixed: possibility to remove hafts from sickles

This was mistakenly allowed. Sickles are a special case and not yet included in the hafting mechanics.

- fixed: skin item duplication if tanning got cancelled at the requirements dialog

- fixed: villagers occasionally wandering impractically far from the village area

- fixed: low quality hafts not degrading the finished hafted weapon quality correctly

You pretty much always got fine hafted weapons even with the inferior hafts.

- fixed: "Of wolf and woman" quest related NPCs selection mess

There was a rare occurrence where the said quest dialogues didn't unfold properly due to the game engine picking the related NPCs incorrectly.

- fixed: paused craft remaining time checks

There was a rare condition where the remaining time to continue paused crafting was calculated incorrectly resulting in too fast completion of items at the end of the process.

- fixed: title song playback interruptions and cracks upon the game starting

The issue was with .ogg file loading. The troublesome audio is now loaded before the title song starts, and some .ogg audio has been replaced with .wav files.

- fixed: occasional white screen flash when player character goes to sleep

- fixed: attempt to haft an invalid target item made the item to disappear

- fixed: sickles weighted too much


Sickle item weight was mistakenly set to 3 lbs. This is fixed now, and sickles weigh 1 lbs as intended.

-----

Cheers!

6

Development News / Re: Spring things, pausable things, future things

« Last post by Sami on May 03, 2024, 01:05:51 PM »

Literally waited YEARS for marriage and kids features to arrive. Can't believe it's finally in the works 

I feel your pain. There are some features that I've wanted to have for years, and they are still not there.
May sound like bit of a joke, but it's actually true.

7

Suggestions / Re: Make Menu only for Modded items = saving BAC and other large mods

« Last post by Sami on May 03, 2024, 01:01:46 PM »

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?

8

Bug reports / [Fixed - 3.83][3.84] wp-javelin = it-brkhaft

« Last post by Galgana 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.

9

Bug reports / [3.84] open mire tiles under tree lack mossy groundcover

« Last post by Galgana on May 03, 2024, 06:58:40 AM »

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.

10

Suggestions / Re: Make Menu only for Modded items = saving BAC and other large mods

« Last post by Brygun on May 02, 2024, 08:03:56 PM »

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.