Messages

1

Development News / Version 3.84.2 - second hotfix patch for version 3.84 released

« on: Today at 07:16:10 PM »

A second hotfix patch has been released for version 3.84.
It's available for all the supported platforms on Steam, Itch.Io and for lifetimers.

The following fixes/changes are featured:

Version: 3.84.2

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

 - fixed: pausable crafting item duplication

         In some conditions when you finished crafting an item the work in progress item still remained on the ground.

 - fixed: using TEXTILECRAFT skill displaying corrupt "Command:" prompt, eg. TEXTILECRAFTNETMAKING

 - changed: Staff item type and role

         Staves are now classified as timber type items rather than weapons, and considered mostly as raw material for crafting and construction purposes.
         There are no changes to staff making. They are made from slender tree trunks by delimbing and debarking the trunk and cutting it to
         suitable lengths. A common staff is thought of being about two meters in length with a diameter that fits nicely in one's hand.

         MIGRATION NOTICE: Weapon type staves obtained in previous versions do work in crafting the same way as the current version staves.

 - updated: STAFF game encyclopedia (F1) entry

---------------------------------------------------------------------------------------------------------------------

Happy patched adventures!

2

Bug reports / Re: Double fire

« on: Today at 11:15:40 AM »

Ohoh, this is new and interesting. Yes please send the save and I'll check.
It's hard to say what triggered this but I'll try to reproduce, and maybe we'll get on track of it.

3

Bug reports / Re: [BUG OR NOT?] Spearfishing, spawning fish, and the lippo

« on: Today at 11:14:01 AM »

At first I don't suspect a bug here. With all the active fishing methods the character tries to catch any fish they can, and in the game world there could be also other fish wandering at the area of the spawning bream. The pike is a plausible catch with spearfishing by the shore even outside the spawning periods.

4

Bug reports / Re: Fire on water

« on: Today at 11:08:29 AM »

Thanks for the save. I'll check even though the issue mechanicsm is hard to find unless it keeps happening again during the test play.

5

Bug reports / Re: Spotting, getting noticed, by unconscious NPC

« on: Today at 11:07:08 AM »

Hmm. Creatures can also regain consciousness (based on the condition checks) and as I don't recall there's a message when it happens so this might not be an actual bug.
A message about "[npc] regains consciousness." would solve the problem, but then again in real life it would be quite difficult to notice - until the NPCs gets up, if they are able to.

6

Bug reports / Re: [3.84p1] duplicated stone axe

« on: May 14, 2024, 10:03:54 AM »

I believe we've got this issue solved and fixed now, and will likely release a patch this week.
Plotinus, feel free to send the savegame nevertheless. Double checking doesn't hurt.

The issue was about unfortunate item data re-arranging due to world/creature activity on specific areas.
The bug potential has been fixed now and no more this sort of duplication should happen in the upcoming patch.

Fixed - persists in 3.84.1

7

Bug reports / Re: [Fixed - 3.84-1]Textilecraft command displays as TEXTILECRAFTNETMAKING

« on: May 14, 2024, 09:17:23 AM »

Fixed now. Depending on character's skill generation order it might display also TEXTILECRAFTBOWYER etc.

Fixed - persists in 3.84.1

8

Bug reports / Re: Fire on water

« on: May 14, 2024, 09:11:09 AM »

Bug it is.
At first I suspect there might have been an NPC lighting a fire somewhere, but then the location had gotten corrupt for some reason.

Did you happen to have human companions around, or somewhere nearby?

9

Bug reports / Re: [3.84p1] duplicated stone axe

« on: May 13, 2024, 11:19:06 AM »

This is likely related to area conditions and data entries rather than individual items.
I'm currently investigating a few other saves of this sort of item duplication, with different items though.

Plotinus, please send the save over. Thanks.
The more samples we've got the easier it is to find out the cause.

10

Bug reports / Re: Of Wolf and Woman

« on: May 11, 2024, 10:31:47 AM »

Heh, a good example about the beauty and challenge of procedurally generated quests.
Of course the main intention with the quests is that they can be solved, but also in a living, procedurally generated world there are countless variables which may interfere - and also sometimes make them impossible to complete.

This case is something we can address, and I'll check up on that, but also NPC hunters might end up in killing the wolf. Or if it would choose to chase an elk, a good hoof kick might sometimes also prove fatal. And so on. This way the procedurally generated quests differ quite a bit from more commonly used static, linear game quests which follow the plot in more predicatable (and boring) fashion.

11

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

« on: May 10, 2024, 11:02:02 AM »

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}

12

Development News / A small patch for version 3.84 released

« on: May 05, 2024, 02:01:37 PM »

A small patch has been released for version 3.84.
It's available for all the supported platforms on Steam, Itch.Io and for lifetimers.

These two issues were cleared, and it may be that the majority of adventurers never noticed their occurrence.

Version 3.84.1

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

- fixed: continuing pausable crafting with inferior tools caused erroneous production times

If inferior tools were used to start and continue pausable crafting tasks the remaining production times were not always set correctly. This glitch occasionally initiated conditions where continued pausable crafting required seemingly endless production times.

- fixed: wrong javelin item tile

------------------------------------------------------------

Happy patched adventures!

13

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

« on: May 05, 2024, 01:16:09 PM »

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!
It's a fun side-effect which several players would sorely mourn the loss of.

Can be considered loosely related. Building a construction clears the tile, so here it clears the water, and the ground remains.
There's no need to fix this, or some other harmless unintended but fun occurrences, as they don't ruin the usual gameplay.

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.

There are various checks for tree placements so it's not completely random, but I don't remember exactly how spring tiles are included in the checks.
So in theory it might be possible, but the chances are extremely low.

14

Solved'n'fixed bug reports / Re: 'Abandoned Trap-Fence' starting scenario

« on: May 04, 2024, 07:19:33 PM »

It's made so that returning the raw materials for world generated fences is left to the game engine.
The engine tries to pick suitable pre-generated items it thinks that the world generator may have used according to the fence crafting requirements.
So it searches for 2 x proper length tying equipment, and is happy whatever suitable items it finds - so ropes in this case.
This is not wrong per se, but it's indeed more in tune with the game world if the tying equipment were always spruce withes.
So it's fixed now, and spruce withes is what you'll get.

Fixed - persists in 3.84.

15

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

« on: May 04, 2024, 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.