Thanks, gonna do that first before I start my next print. This sounds like a really plausible cause!

For 2) I’d also suggest to check out SDL. There are excellent SDL bindings for Rust, and it’s way less involved than dragging in a fully-featured game engine.

Oh, sorry. I stand corrected then.

I’m willing to bet that it’s AI. It soft-contradicts itself quite often, emphasising that C++ is “Performance First”, but then also claiming stuff like “Rust achieves memory safety with zero runtime overhead”.

Edit: What I am trying to say is that I have seen text like this in LLM output quite often, if the LLM is mixing text from different sources in its training data.

Also, there is just wrong stuff in the text itself, not only in the conclusion. For instance the claim that Rust’s type system makes data races impossible. They are easier to avoid, but there is nothing stopping you from writing data races… Here, for instance, have a data race in safe Rust…

I’m new to both, FreeCAD and Blender, but what I’ve been doing up to now:

• Draw the to-measure parts in FreeCAD
• Export them as STL
• Import STL in Blender
• Add decorative elements there in Sculpt Mode.
• Profit

That “Solid Snake Method” sounds a lot like the emacs doctor…

In case you don’t know what the emacs doctor is: It’s an easter-egg of the text-editor emacs (it is, however, mentioned in the manual). The doctor is a chatbot based on ELIZA, and meant to portrait a psychotherapist. Since it is a rather simple script, it is very limited in what it can do, and mostly just reformulates user input as questions.

shocking and horrifying the player is kind of the whole point of the game

I disagree on the “shocking” part here. DDLC is psychological horror. It does have shocking moments, like the end of Act 1, but this is not the main point. It is way more about relationships than about shock moments. Sadly discussing that part of the game (the later acts…) is massive spoiler territory, so I’ll stop here.

The fact remains though, that it is a horror game, and if the end of Act 1 is already too much, then sorry, but it is only going to get worse. A lot worse. (Or, if you enjoy psychological horror: Better. A lot better.)

I don’t know if that’s still the case, but when this game launched it required you to be online while playing (despite it being single-player), and you had to login with a Ubisoft account.

Afaik you can only develop UWP apps on retail Xbox. Aka Windows Phone apps. Aka “those shitty programs with horrible UI that made Windows 8 everyone’s favourite Windows version”.

I made the mistake of buying the Europa Universalis IV base game, and getting 3 months of subscription for all DLCs… Im playing the Anbennar mod, which is a fantasy total conversion of the game. There goes the little bit of spare time I still have…

They only mention “payment processors”, not Visa, MasterCard, PayPal,… So, this does not answer which payment processor(s) are behind the push.

Sorry for being pedantic, but the only confirmed information in that article is “payment processors”. The author seems to just assume that this means credit card companies (what is a reasonable assumption, as said), but it does not sound like that part is confirmed…

Are there trustworthy sources that it’s VISA/MasterCard, or is this speculation?

I mean, I would not be surprised at all, since they have a history of misusing their power (iirc they were the reason OnlyFans nearly went SFW), but before calling names, I’d like to be certain.

This article has a screenshot listing some removed titles (and I think also a link to the original source): https://www.gamingonlinux.com/2025/07/valve-gets-pressured-by-payment-processors-with-a-new-rule-for-game-devs-and-various-adult-games-removed/

Yep. One reason why those situations become less frequent over time is that one learns to avoid such designs. Thought process: “Sharing data across threads is annoying. So I’d rather avoid it. Maybe message passing can solve the same problem as well?”

This is so fucking stupid, I can’t even.

For your mental health, have some reasonable arguments about Rust: https://www.heise.de/hintergrund/Entwicklung-Warum-Rust-die-Antwort-auf-miese-Software-und-Programmierfehler-ist-4879795.html

Since it’s in German, here are the key points of the article (written from memory - the article is quite old, so I might misremember - best read the article yourself):

• Software development is stuck in a vicious cycle regarding project budgets.
  • Some competitors don’t know better and just budget the “happy path”, that assumes that everything during development goes right.
    • The author uses a term for this which I like a lot: “Hybris of the programmer”
  • Other competitors know better, but still have to lie in order to remain competitive when it comes to prices
  • Therefore almost all software projects end up with a way too low budget
    • So we get buggy software
• Rust might be a way out of this misery, because
  • it is understood that it takes longer to develop something with Rust
  • but on the flip-side the safety-guarantees rule out a lot of bugs
  • so customers who choose to have their project implemented using Rust are fully aware of the higher costs, but also the higher quality
  • and developers have a well known argument for the higher costs, and also have data that shows how this higher investment will yield a better quality product.

Brave? You mean “browser for bigots”?

https://www.standard.co.uk/news/tech/mozilla-boss-brendan-eich-quits-in-row-over-his-opposition-to-gay-marriage-9237701.html

No solution, but I have a similar issue with the higher crate.

There the /prelude/src/lib.rs file lets rust-analyzer lose its mind and allocate gigabytes upon gigabytes of memory, even though the file compiles just fine and nearly instantaneous…

I think this has something to do with recursive macros. Doesn’t iced also have such? I have faint memories of a column! macro?

• cargo install is for installing rust programs for your user, not for adding dependencies to your Rust project. Many cargo subcommands can be installed this way, for instance cargo bloat.
• The file you are talking about is called Cargo.toml, because it is the file you need to write in order to configure cargo for your Rust project. TOML is the name of the file format. For details, please see the introductory chapter to Cargo in the Rust book.
• Cargo recently got a new subcommand called cargo add, which allows to add dependencies directly on the command line. However, all it does is to add/edit/remove the respective lines in Cargo.toml. (Personal opinion: I have found it way easier to just edit the file directly than to learn yet another command…)

That said: You still need to edit the Cargo.toml file, even if you solely use cargo add to manage your dependencies. That’s because that file contains a lot more information about your project than just the dependencies. For instance the current version, the feature-flags, your name, a link to the public repo,…

I haven’t done much Rust coding this year yet, mainly because I am trying to learn Lean4 and spent the last couple of months writing a (partially) formally validated (but not very fast) Binary Heap in Lean4.

However, a few days ago I had an inspiration at night, that brought me back to my Rust spare time project: The visual novel engine I had started last year.

For now I only did a relatively small change, but it’s one that will save me a lot of time (and nerves) later on. I am using a Free Monad based embedded Domain Specific Language for writing the game logic. The change now was to wrap that Free Monad in a State Monad Transformer, which I use to store the game state in.

This idea seems to be working surprisingly well, and that has given me enough motivation to return to this project and to keep developing it further for now.

Long and boring explanation with way too much detail:

Sorry for going on a tangent, but there is a Rust-specific detail that makes this cool beyond the usual advantages of using a State Monad Transformer, and I cannot stop myself from sharing.

For composing a large Free Monad, do-notation is more or less a must-have. However, do-notation in Rust only works well with types that implement Copy. If you want to use any other type in do-notation, you can only access variables of it in the following two lines. An attempt to access the data later will lead to an ownership problem (explained here). I have tried to overcome this by adding additional syntax to do-notation, but that is a crutch at best.

So, this is where the State Monad Transformer comes in. It side-steps this problem by moving the state out of the do-notation block into the Free Monad’s Pure-nodes. That way it is readily available via the State Monad Transformer’s get()/put() functions, and the “use within two lines” limitation is not a big issue any more, as one can always get the value on one line, do something with it in the next line, and write the result back on the second line.