Sleeves

I looked at slackware's packages and it seems that, in version 15, the latest version of glibc is 2.33. Given there seems to be no glfw package (at least not an official one), I think your easiest solution would be to simply download an older glfw version that works with glibc 2.33 - a quick search told me 3.3.10 but I couldn't immediately find a concrete answer. Then you'd tell Vintage Story to use that copy instead. Though it may not actually work with the game, which is always a concern with downgrading packages.

Given OP's nicer behavior after the initial post, I think they probably just got a little frustrated after the game threw too many bears at them. I don't know about you, but I'm not immune to some venting after having a tough time with a game. If there's anything that you just can't grow to like, remember the game has an excellent modding scene. Plenty of quality of life, difficulty modifiers (in both directions), and mechanical changes are available on the database :-]

True or not, it's always a good opportunity to test software on different systems to ensure everything's properly modular. Ideally the game will run on any system with the correct dependencies; if not, something's wrong and needs to be fixed on the game's and/or the system's end.

Note to anyone else who encounters this issue in the future, flatpak or not: if all else fails, you can make a desktop entry yourself. It should look something like this: [Desktop Entry] Type=Application Categories=Game; Name=Vintage Story Comment=Uncompromising wilderness survival sandbox game Exec=/usr/bin/vintagestory Path=/opt/vintagestory Just replace Exec with your game's binary file and Path with your primary game folder, then save it to wherever your desktop files are. For me it's /usr/share/applications/vintagestory.desktop

I think part of the appeal of having precise chiseling despite blocky terrain is the ability to choose what to detail. I often use single voxel chiseling for layering; to make the linings of walls pop out, give rooves an overhang, et cetera. This would be lost were everything in the game detailed.

Excellent work! Been using this for a couple weeks now and haven't had a single issue.

I ended up using a similar format to ini for configuration, as I realized there's no good reason to store dependencies separately from their modinfo definitions, and thus no need for nesting. Profile definitions now look like this: name="myprofile" [mods] coolmod="1.2.1" library="0.2.6" coolermod="3.2.0-rc.2"

That would honestly be way better than the volume-based hit registration I suggested, both for comfort and latency. Especially if clubs could hit multiple enemies at once like this; they would finally be useful!

I've been rewriting my old mod manager (https://mods.vintagestory.at/octatonic) on and off for some time now, and I'm about ready to take its development seriously. This time I'm being much more practical about what really needs to be modular and what doesn't- my prior attempt at a rewrite split the manager into a library and a frontend, which was honestly quite unnecessary. Because I want a solid base to build on, I'd like to discuss some of my design ideas (and uncertain aspects) before hammering out a release. Profiles The new version will center around profile management, a feature which was implemented poorly late in its predecessor's life. Profiles are stored in your data directory (by default, $XDG_DATA_HOME/octatonic) as folders consisting of a header file (working name, please suggest a better one), a mods folder, and a config folder. Any given mod version appears once in the store directory, e.g. <data_dir>/.store/carryon/1.21.1 - the actual mod file is symlinked to whichever profiles use it, and the whole folder deleted if all references are gone (will likely be optional). The interesting aspect here is how the current profile works. A persistent .current directory is used as a checkpoint for the actual profile you want to use. Should I load a profile titled wolfbait, the contents of wolfbait/mods and wolfbait/configs will be symlinked to the respective .current directories. Saving a profile empties its folder and symlinks the store paths of everything in .current in its place (or, in the case of configs, copied). Note that this design decouples octatonic from your game install; all you need to do is link .current/mods to VintagestoryData/Mods and .current/configs to VintagestoryData/ModConfig! Of course, that does mean it won't manage VS itself, which is something I'm on the fence about. Prompting Octatonic will prompt you if something needs specifying. For instance, imagine you install a mod via command and the latest version is a pre-release. You would see something like this: info: current release is not of stable branch [1] 1.0.5 [2] 1.0.5-pre.8 [3] show more ==> 1..3 | v <version> This promotes quick usage without assuming what the user wants. Dependencies Dependency resolution will rely on the same VS-flavored semantic versioning scheme as modinfo files and will prompt (see above) when installing a hard dependency with multiple permitted versions. Ideally, I'd like to prompt the user before removing a mod if another depends on it, but I'm not sure if or when this will be added. Optional dependencies will not be managed unless they are officially included in a modinfo specification. Example Structure I realize describing file paths sentence-by-sentence is rather confusing, so here's a little diagram of the data folder: - octatonic - .store - mymod - 1.12.9-rc.3 - mymod.zip - 2.5.4 - mymod.zip - trampolines - 0.3.2 - trampolines.zip - .current - mods - mymod.zip (linked from myprofile) - trampolines.zip (linked from myprofile) - configs - trampolines.ini (linked from myprofile) - myprofile - mods - mymod.zip (linked from .store) - trampolines.zip (linked from .store) - configs - trampolines.ini Limitations The main drawback of the approach I'm taking is that I doubt windows support will be plausible. To be fair, I don't know how many people used the old windows versions, nor do I imagine most windows users would prefer this tool over the now-abundant GUI alternatives available. Still, it's a regression. I also don't think modconfig files will be tracked (i.e. indexed in the store, listed in profile headers) because the benefits appear slim at best. Discussion None of the previous ideas are set in stone, and only half are yet implemented. Please share any thoughts you have, lest I build the tool on a weak foundation. One point I'm particularly undecided on is what configuration format I'll use for profile definitions. Right now I'm looking at KDL, but other candidates include JSON and SCFG, and I'd love to hear about any others which may be better-suited. Also, what would your preferred workflow look like? Do you prefer an interactive or fuzzy search? Would a custom format string when listing your mods be worth the trouble?

I feel this is true of all the dialogue, which makes sense given the system itself is fairly recent. For an obvious example, traders all say the same things (except those related to the questline) and don't "remember" what you say, so you can ask them their names repeatedly without the option disappearing.

NOTE: This is a repost of an article I wrote to my (terrible, inactive) gemini blog some time ago and I have changed my mind on a couple points, but I think there are some interesting ideas worth sharing nonetheless. I also edited the text without significantly changing its meaning. A large portion of players find the game's combat systems lacking at present, but few agree on how to improve them. I can't solve that issue, but I can add to it by throwing my own opinions in with the others! So anyway, here's my little proposal. MELEE HIT REGISTRATION Hit registration for melee is done in one of two ways, depending on the weapon and attack type. Direct attacks use hitscan augmented with some auto-aim, because aiming is never really a challenge in combat; it only makes small targets annoying. Perhaps aiming would have been more relevant if enemies had weak points or incomplete blocks (i.e. a shield you can stab around). Area attacks use a moving hitbox, permitting multi-target damage. The downside is that you need to physically aim, which can cause problems for the player when enemies are too short (e.g. rabbits, crawling drifters). ATTACK TYPES Basic attacks can be performed by pressing the attack button, and strong attacks by pressing twice. Both moves can be performed continously by holding the button; for strong attacks, the second button press should be held. Generally, basic attacks are fast and use direct hit registration. Strong attacks tend to be powerful and use area hit registration. SPECIALTIES Traits are denoted by an asterisk (neutral), a plus (positive), or a minus (negative). SWORD Basic: Stab * Direct + Speed * Range * Damage Strong: Swipe * Area - Speed - Range * Damage SPEAR Basic: Stab * Direct + Speed + Range * Damage Strong: N/A - see RANGED section CLUB Basic: Poke * Direct + Speed + Range - Damage Strong: Strike * Area - Speed - Range + Damage AXE Basic: Chop * Area + Speed * Range - Damage Strong: Split * Area - Speed - Range + Damage SHIELDING Shields are guaranteed to absorb damage when held. Absorption starts at a fairly high value (dependent on tier), but quickly reduces while continuously blocking. The value resets upon re-initiating a block. Blocking has a 0.6 second cooldown regardless of held duration. Absorbing damage does not end a block, nor reset its absorption. RANGED Two special ranged features are detailed here. Ammo fragility is dependent on the relationship between the target's and projectile's damage tiers. For instance, a steel arrow is less likely to break from hitting a raccoon than a nightmare drifter. Shred refers to any effect that only activates when the target's damage tier is lower than the projectile's. SPEAR Damage ramps up while charging spear throw, reaching its maximum after about a second. This discourages spamming. Spear has high damage and a more pronounced ammo fragility effect^1, but cannot pierce enemies. ARROWS Arrows are guaranteed to pierce the first enemy they hit when shred applies to said enemy (see above). ^1: More pronounced meaning it takes even less damage from hitting weaker targets. I believe my logic was that a multi-foot rod should be relatively unaffected by a hare or the like. Note that spears should have a lower base durability to compensate; they're powerful enough as is.

It is helpful, but perhaps better left in wiki territory, lest newer players bounce off the handbook thinking it's too complicated. (I say, as if this doesn't happen already...)

Were a simpler version desired, the debuff could apply when health drops below a threshold.

I think the problem is moreso how randomness factors in. Sometimes you find everything you need immediately, but in other worlds you go upwards of fifty hours without finding that one resource you need to progress. I don't think there's any great solution to be had, although bad luck has become much more tolerable with the addition of elks.

Low oboe, always.