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.