Katherine K

Apparently, it's a parameter you can pass to the executable, --addModPath followed by the path to the folder containing the mods. I haven't tested it, but the name seems to imply that you can have multiple such paths added, one for each modpack, effectively. Of course, that means that you'd need to then create either a custom .bat file or a shortcut with command arguments for any combination of mod folders you want to enable/disable. It wouldn't be too difficult to create a launcher for this, as was briefly discussed in another topic. If this isn't something actively in development by VS team, it could be a community project.

Oh, neat. Yeah, if the engine takes mod paths as a parameter, that removes the hassle with virtual file system. Technically, this means that people can just make .bat files to launch the game with different mod packs as a temp solution.

If there's no official support soon, one will need to be created unofficially. I don't know if there's an easy way to make it work entirely within the game, but it'd be pretty straight forward to set up a launcher that feeds a virtual directory structure to the game. Kind of similar to how some mod organizers for Beth games work. That would let you select a mod-list you wish to apply, and this can simply only have the selected mods show up in the directory structure that the game sees. Since something like this would also be feeding the config file through the VFS, it'd be pretty straight forward to also set up a session manager in there.

Not even necessarily negative ones. A lot of people will make comparisons between MC and VS simply on visuals, and make assumptions about what VS is as a game based purely on that. I'm sure it gets old fast for anyone actually playing VS and knowing that similarities are largely superficial*. * There are definitely deeper similarities, but they have more to do with how the game functions under the hood than how the game plays, if that makes sense.

Modern (and I mean past 10 years or so "modern") rendering hardware is primarily limited by memory bandwidth, not triangle counts in any realistic setting. If they take up the same surface area on the screen, it rarely matters if you render it with one triangle or 2 to 4. Your bottlenecks will be in rasterizing, texture fetches, lighting, etc, and that doesn't scale with triangle count all else being equal. Besides, a single tree in VS takes up at least a typical chunk's worth of triangles. Not to mention any chiseled structures, including generated ruins. The impact of going to a slightly higher triangle count of terrain is negligible. Machines old enough that it'd make a difference to aren't going to be able to run VS at anything other than a slide show rate to begin with.

Ventilation might be a bit much in terms of impact on game mechanics, but the rest would be pretty easy to implement.

My Steam library is full of indy games that I'm never going to play, but I want the teams that made them to make more games. I'm not saying it as "This is the way," and I also realize that people have very different budget constraints on gaming. But it's weird that we're letting giant corporations get away with turning games into services that can be shut down any moment they stop being profitable, but we demand a finished product from indy devs. I really think we should flip that around. An attitude where we demand ownership of a complete product for our money from the corporations and treat purchase of indy games as an investment in the team would be more healthy for the industry and result in better games on both ends of the spectrum.

Yeah, most of the drop amounts would be easy to adjust to 1/2 and 1/4 blocks. And I don't think it'd be a bad thing for these not to be exact. If the full block of clay normally drops 5 clay, 1/2 block dropping 2 wouldn't be throwing the balance off or anything. I don't think this makes sense for any but the surface blocks, so you shouldn't have a problem with multiple materials being mixed together. But this does introduce potential problems with soil. Nothing unsolvable, but changes are likely to go beyond simply world gen and will result in some gameplay adjustments. There are interesting edge cases with grass and tree placements too. It'd be a project, for sure. Entire terrain's voxel. But there's a sub-grid for the blocks, yes. Game's pretty good at handling sub-blocks, and there seem to be some optimization for slabs. Going down to 1/2 or even 1/4 blocks shouldn't be a problem performance-wise. I won't go so far as saying that it would have no impact on performance, because I'm not that confident, but I would be shocked if it's significant.

Yeah, I certainly see how that puts people on alert. There are a lot of tempers and finger pointing, and some choices being made. But the situation this most reminds me of is all the drama surrounding Hiveswap, the Homestuck game, with all the delays, and developer changes, and flip-flopping between 2D and 3D. And meanwhile, Toby Fox went off and made Undertale, which was a lot closer to what the fans of Homestuck actually wanted than Hiveswap ended up being years later. I think there's an opportunity for something similar here. Not in scale, but just the general outcome. Even if Simon makes the deal with Riot, it sounds like he's trying to prove something with it. I don't believe for a moment that the game's going to be released to the general public any time soon, because it'd be a vanity project at that point. In the mean time, VS team can just go and make the adventure game people actually want to play. Without the Hytale logo or the attached baggage. And they really seem to be in a unique position to do so. I don't know if that makes it the wisest business decision, but I also don't think it's reckless. And at the end of the day, if we want games to be art, we have to recognize the need for the artist to take artistic risks. I think that's one of these moments.

You did start it from hl.exe originally. It was separated out into its own project later. It's already been said that adventure mode might end up shipping as a separate product, depending on how things go with it. That's always an option. The question's only about how it's developed. You say that, but it's exactly how HL multiplayer worked. It was a completely separate "game" packaged with HL, using some of the same assets and the same engine, but also having a whole bunch of separate assets and its own client and server DLL files. That was developed entirely by Valve in house in parallel with HL single player, and was started using the same executable.

You probably do. Ever played any of the Source Engine games? Counter Strike? Team Fortress? How about any of the games built on id Tech? I know it's been a hot moment since either of these have been popular, but a couple of decades ago, this is how a lot of best games were made. In the early days, they'd straight up use the same executable, maybe shipped with different build of it, but functionally interchangeable, and you'd just change the folder the engine looks for assets and game/server .dll files in. You could jump from playing one game to a different one by running a console command in the game. The reason people don't do this anymore is because almost nobody's making games on their own engine with an indy studio. Almost everyone's either using a 3rd party engine, like Unreal, or they're using an in-house engine in a giant studio with hundreds of people working on each game, and where keeping these separate is just a way to prevent four hundred people you never met making changes that influence your game. So the mod manager will have to have multiple mod lists. It's been a highly asked for feature and now it will have to actually exist. I fail to see a downside. That's... Not how you write game code. This isn't Balatro. Anyone who thinks that an if/else statements are a good way to handle different special cases of game elements and UI need to learn better coding techniques. There is inheritance, interfaces, and virtual methods to handle all of that. And crucially, that's how VS already works. If you know any C# at all, I encourage you to look through survival mode's source as it's public. These things are already part of the survival mode. They're not part of the core engine. Again, feel free to take a look at the source code. It's well structured.

Data loss on a crash isn't particularly surprising, but I am a bit surprised about the crashes being common for you. Are you running lots of mods or one of the RCs?

Fair enough. I might be a coffee snob, but I won't force it on anyone else.

Turkish is traditionally made in a cezve, and there's art to heating it up in the hot sand, rather than directly over flames. Though, I've been able to get decent results without the sand - you just have to be way more careful not to overheat the cezve. Point is, you can't just stick it on high heat and wait for water to boil. That won't make a good coffee. You can get a coffee by pouring hot water over grounds in a cup, but you get no real control over the brewing parameters. The steeping time is invariably too long, which means you're going to get all the harsh oils from coffee whether you like them or not (and you probably don't), and even the grounds size doesn't matter that much. It is absolutely the worst way to make coffee, and even limited to primitive technology, I don't see why you'd go for that.

That doesn't work quite like this in practice. Even in Keen's case, ME and SE didn't quite share the features. ME is a bit like a 1.5 version of the engine. And it's a big part of why the update to SE2 took such a separate path. They share parts of the engine that might even start out as exactly the same engine, but they always diverge. I've worked on several games that shared an in-house engine forked to two separate branches. Notable examples include Star Trek Online and Neverwinter at Cryptic and Marvel's Avengers and [Redacted] at Crystal. Even when both games are pre-release, as was the case when I worked at Crystal, the changes from one branch don't always make it to the other. We struggled with that at Crystal, because each project is running on its own schedule, having code locks at different times, meaning features can only be cherry-picked at specific times. If something got dropped, and it's not critical for your game, do you go back and pick it up? Or do you worry about getting features you do need for the game ready? And it gets so much worse post-ship. Neverwinter ended up with its own animation system, that internally was known as v2. And we had a core team responsible just for the engine. And I still basically had to maintain two separate animation systems until I got a green light to back-port v2 to STO like two years after Neverwinter's release. And it was a project. VS is in an amazing spot regarding this. Engine and game mode are genuinely separate projects. Survival's entire code is up on github posted officially, because it's that separate from the engine. You actually have to have the engine team maintain features for both in parallel, because you're not just starting with a common code base, you are sharing the engine. And sure, when you release it to the public, you could make them separate executables and have them marketed and sold separately. But this has nothing to do with how the game is made. That's just about the wrapper, the presentation. The game would still be made as an adventure mode on top of the shared VS engine. That's what we're talking about here. Wasting time at this juncture pretending that you're treating them as separate games would be performative at best. At worst, it'd actually be demotivating to the teams working on it.

Moka pot could be another craft recipe to use solder and soldering iron. And whenever steam power update arrives, that should come with espresso machines. And I'd absolutely love to have tea pot as a clay recipe. I imagine it working exactly like a cooking pot, but only accepting water in its first slot and limited to maybe 4 portions? I imagine teas being just herbal soups that can take honey and berries in extra slots. You'd still be able to make tea in a cooking pot (or a soup in a tea pot if you want, I suppose) but tea pot would let you pour the contents into the placed bowls, rather than the taking food out of a cooking pot with a bowl. Though, having actual cups in the game might be nice. Could limit the tea pot to just 1L letting you serve 5 200ml cups of tea then?

They'll make stuff up even if it's within their training set, because they are trained on matching text, not semantics. You really shouldn't be delegating your thinking to LLMs. Not only is it making you worse at thinking due to not having as much practice (thinking is a bit like going to the gym in that aspect), you have absolutely no way of telling when you're getting good results. That aside, the entire source code for smelting logic is public. Relevant function call: public float changeTemperature(float fromTemp, float toTemp, float dt) { float diff = Math.Abs(fromTemp - toTemp); dt = dt + dt * (diff / 28); // Various early outs if temperature is unchanged or reached maximum. return fromTemp + dt; } This function is used both to update the fire pit temperature and to update the temperature of the contents of the crucible. The difference is in how the dt parameter is supplied. For the fire pit temperature, dt is just the time tick. For the crucible, however: float f = (1 + GameMath.Clamp((furnaceTemperature - oldTemp) / 30, 0, 1.6f)) * dt; if (nowTemp >= meltingPoint) f /= 11; float newTemp = changeTemperature(oldTemp, furnaceTemperature, f); So in other words, the crucible heats up 2.6 times faster if the temperature difference between the furnace and the crucible is at least 48°C. Since that's practically always up to melting temperature, we can just run with that as the equation for the heat transfer: dT/dt = 2.6 + 2.6 (Tₘₐₓ - T) / 28 Setting T = 0 at t = 0, and assuming your firepit has already warmed up, this can be solved analytically: T = 2.6t + (1 - exp(-2.6t / 28)) Tₘₐₓ So for example, here's copper heating up to its melting point of 1080°C in a little over 17s. I've just tested this in survival, and it's pretty much spot on. I waited until the fire pit got to around 1280°C, added 20 copper nuggets to a crucible at that point and started the stopwatch. When copper reached 1080°C I stopped it. Stopwatch just rolled over past 18s. Given that I was a bit sloppy on timing, I'm pretty sure the extra second was me being slow on the stop watch. Note that this assumes the firepit was hot. But so is the model you're quoting from Wikipedia that you fed into AI. So the numbers you got from AI are straight up wrong. Which should surprise absolutely nobody who knows how LLMs actually work. I suspect, it didn't even try to linearize the curve and just took the k as the slope, which is basically random garbage. The reason this might feel like it's taking a lot longer is that people usually put the nuggets in first, then add the fuel and light it. That takes considerably longer, because fire pit has to heat up as well, and it heats up slowly, but also, the model is way more complicated. Especially, if you're juggling multiple different fuel types. Trying to estimate it with a line is just not going to work. In summary, the numbers AI gave you are completely wrong and essentially made up. They are way larger than what they should be. The reason they feel right is because what you're doing is actually very different. You're waiting for the fire pit to heat up, not the metal. And since you're using different fuel types, the heat up portion is taking extra long. (It's still coal efficient, so that's fine.) The actual smelting time starting from cold fire pit being anywhere in the ballpark of AI numbers is pure coincidence. I can put together the correct curves for heating up starting from cold fire pit with different choices of fuel combinations, if there's interest, but that will turn into a longer post, and I'll have to use Mathematica to make the plots. So let me know if anyone wants to see these.

Such a weird interaction, though. A shared shader variable that's not being updated in the right place? That's the only thing I can even think of.

Bait used to be believable.

Agreed, it's a mixed bag. On one hand, it lets you run raw machine code, so you have all the wonderful capabilities. On another, it lets you run raw machine code, so you have all the less wonderful vulnerabilities. Then again, so much of modern development ecosystem is, "I needed this feature, so I imported a package. No, I don't know who made it." Maybe it's a lost battle, and we'll just have to rely on mod aggregation sites being properly reviewed and moderated. I liked how in Space Engineers the terminals did run custom C# if you had the right settings turned on on the server, but it was passed around as text and compiled on target machine with stuff like IO and unsafe execution disabled. And it's not that you can't hide a back door in that, but you have to write something that will instantly look suspicious to the right person and would at least be more likely to get analyzed and flagged. As much as I'd love to always have capability to run native code for performance on particularly heavy tasks, like what's discussed in the Advanced Hydrodynamics thread, having the mods be limited to C# that's distributed as source would be safer. Not safe. But safer.

Personally, I don't feel like rifts add anything to the game, so I play with them disabled. You still get monsters spawning in caves, and it really feels like that's where they work better in the current state of the game. Ditto temporal stability. I disable it entirely, but I would prefer an option to have it disabled on the surface only. Temporal stability dropping while you're caving makes perfect sense. On the surface, it just limits where you can set up your base, and that doesn't seem fun. Obviously, a lot of this is quite subjective, but I do think that current state of the rifts, temporal stability, and temporal storms falls short of some of the objective bars for good game design. A mechanic that becomes a chore instead of a challenge once you progress and learn how to deal with it is not really a good survival sandbox mechanic. Rifts and temporal stability limits how and where you build, but not in a way that creates an ongoing challenge. You just learn how to properly light and spawn-proof your base, and you spend more time picking a location because now you also have to make sure the gear spins in the right direction when you're there. None of it makes survival harder. It just limits player choice. Similar situation with temporal storms. Enclosing yourself in a 2x1x2 space solves the problem, but that just isn't fun. And I get that playing optimally does not have to be the most fun way to play a game. But there is a difference between playing a fun way not being optimal and it being actively punished by the game. The boundary between the two is going to be very different from player to player, so no solution will ever be truly universal. I completely understand the players that Leeroy Jenkins into the night during a temporal storm armed with a bronze falx and adrenaline. The problem's that it's basically that or hiding in the hole. You either take an action route or you make yourself completely safe in a dirt hole and go make yourself dinner while the storm passes. Neither of these fulfill the horror aspect and that seems like the entire point of having temporal mechanics in the first place. So I'd like to see these revised. They're great narratively and thematically, but I really don't think they're there mechanically. Until some major changes happen, my recommendation is that if it makes your experience worse, just turn them off.

That's the sort of thing that I usually think of as part of gameplay code, rather than engine. But I suppose, VS has a somewhat unconventional engine/gameplay split, so I can see how having a framework be part of the engine would make it a lot more convenient to work with. Just something to store mode-agnostic data attached to a character or entity, with any processing/procs/ticks still being handed by the mode (or any mod, really). Nothing stops you from just having a lookup in the mode now, tbh, but a framework would make it cleaner and easier to mod. So definitely a win.

Yeah, behavior in response to a player that's out of detection range is wonky. I'm glad attacked creatures don't just magically know where the attacking player is, but the response should be something other than shrugging it off like it must have been the wind. Seems entirely reasonable for the creature to know roughly the direction where the attack came from and either get closer to investigate or flee, depending on the type of creature and the amount of damage.

I'd take it with a grain of salt. A lot of this mirrors closely statements Simon has been making about Hytale development lately, and while I don't want to accuse him of intentionally misrepresenting the situation, from his posts, he comes off as someone who embellishes the situation a bit. Not in a snake oil salesman kind of way, but rather as someone who's excited about something and wants other people to be as well. And since he's currently trying to retake control of the Hytale IP, that is coming out a bit one-sided. Specifically, he started claiming that the game was ready to ship, but then backed down to early access when pressed on it with questions. Which, I'm not saying there would be anything wrong with shipping Hytale as EA if it's developed by an indy studio, but "ready to ship," implies a very different state of the game. Ready to ship is gold, polished, post-beta. EA is a late-pre-alpha to early-alpha build with a vertical slice polished to beta quality, and it's mostly that slice that gets shipped. There are months or years of work in between. And I've heard different accounts of the engine swap, which ranged from, "This was completely unnecessary and sabotaged the project," to "It was necessary to do eventually to support all the features the team wanted to for full release, and releasing EA before the engine swap would just leave EA in limbo with no updates until that's done." The truth is probably more in the, "It's complicated," pile. Simon insisting that it's purely the former makes me skeptical of that account. All of this is with the caveat that I don't know the person; I'm going purely by recent and some historical posts. And I don't want to make it sound like someone's intentionally lying or obscuring the situation. Just cautioning against taking that as the whole story. That said, yeah, there is no reason to doubt that the playable, fun version of Hytale existed within the studio at one point. The disagreement is purely on how much from the original pitch was missing, whether that was critical, and whether it could be built up incrementally on top of a released EA. And these last two points are conditional on who's releasing the game. Building your own minigames Roblox style was a big part of a pitch, and probably very important to Riot for monetization. It might not matter nearly as much to an indy game, and they can just settle for "modable", for example. If these sort of compromises let you keep the old engine, then EA's back on the table, etc. So I'm still curious to see how all of that Simon-negotiating-with-Riot story plays out.

There's so much that goes into a game project failing, though, that's far beyond whether the concept and the team are good or not. I don't want to reduce this to "luck," because that would imply that better decisions were not available, but making a game is a bit like putting together a team for a heist. If everyone worked as a team, but the person whose job it was to get the plans for the bank vault didn't get the correct schematics, and the safe cracker was preparing for the wrong type of a vault mechanism, well, maybe they still can do their job, but maybe not. From outside, it just looks like a failed heist. If you know the crew and the job, maybe you know what needed to be different. I admittedly know less about what happened at Hypixel Studios than probably anyone on the core VS team, and possibly even less than some other people on this forum, so I'm filling a lot of the blanks with general dev experience. And I don't really know anyone from the pre-acquisition by Riot days. I know a couple of engineers who got hired after that, and might've heard a few things that aren't general knowledge, but nowhere near insider levels. So take this as an educated guess or complete conjecture if you will, but I have been paying attention to the updates as they were since the first announcement through a lens of someone who's been working in the same field. My take, for what it's worth, is that the crucial failure points of Hytale as a project are in things that Vintage Story as an engine and a platform has already successfully navigated. One of the big stumbling blocks for Hytale has been the engine. I still only understand game design and art at a hobbyist level, but game engines are literally my job, and VS has an elegant, flexible engine which is the exact fit for the parameters of a project like Hytale. There's a shit ton of tech art work that needs to be done, and probably some improvements to the renderer to make it an aesthetic fit, but mechanically, I can't name you an engine that does the job better for what Hytale needs. The only thing I'd call out as a big missing feature is better enemy behaviors and AI, but I don't think it's a huge challenge to implement these, and it sounds like that just wasn't high on priority list for VS. There's obviously more to it: the combat, the crafting mechanics, magic and enchantments, more player interactions and socials. But these are things that you'd generally find at gameplay level, rather than engine. Think of it like things that'd go into a mod vs core engine. The engine already does nearly everything I can think of. The gameplay features on top of it have to be built out. Design, code, and art. But that's just the standard craft of making a game. The other big part was Riot's expectations. It's not that Hytale as a concept can't explode to Minecraft or Roblox levels of popularity. It's that it's not guaranteed to. I think we all would call Vintage Story a success already, even if it never gets bigger than it is now. But Riot can shit out a cheap mobile game with one of their IPs, and it will perform better from purely financial side of things. The VS scale just isn't worth the trouble for them. They needed Hytale to be Big or they needn't bother. But without Riot's involvement, it really doesn't have to be an enormous success to be a successful indy project. It might still grow into one, but it's not a failure if it doesn't. If you look back at that original 2018 announcement trailer, and that scale of the project... If that exact concept started its life as a VS mod rather than a Minecraft mod, I think it might have just hobbled along to a launch with no other changes to the timeline. And there is a lot in there that is well proven on MC mods and non-blocky RPGs. Minigames, PVP, raids, general progression, socials... These are, in industry terms, solved problems. There are people who know how to make these things fun. Visually, the style seems to be well received, and while a bit niche, it isn't a risk factor. That adds up to a successful game when it's properly staffed and managed. With that in mind, I can absolutely see a way that somebody intimately familiar with the project and well acquainted with people who worked on it through the years, could look at this and see a way to succeed where the original team failed. This isn't trying the same thing again and expecting a different result. This is quite literally trying to do things differently to get the result you actually wanted.