site banner
ArjinFerman  Tinfoil Gigachad  1mo ago (text post)   554 thread views

Tinker Tuesday for October 14, 2025

This thread is for anyone working on personal projects to share their progress, and hold themselves somewhat accountable to a group of peers.

Post your project, your progress from last week, and what you hope to accomplish this week.

If you want to be pinged with a reminder asking about your project, let me know, and I'll harass you each week until you cancel the service

2
Top Bottom Old Controversial Comments
Jump in the discussion.

No email address required.

Still refactoring. The content import seems to be working and is a lot cleaner now than it used to be. If all goes well it will even be able to serve all other content sources (Substack, Youtube, etc.) without further modification. I'm currently rewriting the frontend to work with the new data structure, and with any luck I won't be needing separate components for each source either.

I also took a small detour. The database grew a bit over the months and I started noticing the app isn't as fast as it used to be. Turned out that some things I thought I'm handling in bulk ended up being translated into individual queries, some indexes I could swear I set up weren't actually there, and I somehow slept through recursive queries, which I've been dreaming of having for a while, actually becoming available nearly a decade ago. Oh well.

How have you been doing @Southkraut?

Fairly well, actually. Stole some minutes here and there and managed to discover that one of my greatest sources of consternation - my actors spawning in at (0,0,0) instead of wherever I nominally put them - was because immediately after spawning them, I programmatically assigned a new rootcomponents to them. Now, I expected the rootcomponents to assume the position of the actor, given the methods and parameters with which I attached them...but it's the other way around. So it goes.

Now my remaining issues revolve around the physics.

  1. Why do some of my actors collide with the terrain, while others fall through?
  2. Why do my actors constantly and rapidly accelerate in unpredictable directions?

And when I get a handle on that, I'm on to the somewhat more freeform

  1. What's the best way to attach to physically simulated actors together, given my use cases?

Why do my actors constantly and rapidly accelerate in unpredictable directions?

This is usually because they were spawned partly in an object / terrain, right? The physics engine prevents clipping and collisions by producing a force to push the offending objects apart, but if the objects intersect too badly this force can be huge and sends it off into space. Most obvious when you spawn an object intersecting terrain, b/c terrain doesn't move and objects go flying.

That's what I originally thought, so I instead spawned my test actor in perfectly empty space far above the terrain (and let them drop). It still went flying off unpredictably.

Also, I wish I could just turn off that force. I wish it even had a name! It keeps meddling with how I want to resolve collisions.

You could turn off collision shapes and attach your own as some kind of custom attribute maybe.

I had this problem in a small custom engine that I threw together for my own amusement. I showed it to Claude, and it made a bunch of rewrites that fixed the problem.

Since that can't be applied to Unreal, I'm not really sure how else to deal. I'd probably try to write something to identify when the problem happens and counteract it, but in my example that just made it worse.

I don't know Unreal, but I'm getting the impression that objects you're spawning have child/subobjects, could it be that some interaction between the child objects sends the root node flying?

Yes, and that's what I thought too! So I just spawned an actor with one mesh and one collider and nothing else attached to it. And it still flies off! Almost like I drunkenly trolled myself by hiding some code somewhere that repeatedly randomizes the direction of gravity on a per-object basis.

Oh, I forgot, but I had this same problem one time because my mountainous terrain was being automatically turned into a simple convex. So huge amounts of apparently empty space were part of the collision object.

Oh! That's a good one. I'll check for that; I can absolutely imagine it being the case. Thanks.

Why are we here, just to suffer? At work they at least pay us for it, but then we do it to ourselves in our free time...

I am struggling to maintain motivation on the game I'm making (previously mentioned here ). I've spent too much time making stupid placeholder GUI stuff and it's taking too long to get to the cool gameplay features that I actually care about. I am reconsidering my stance on doing everything from scratch. Does anyone know of any useful libraries or stuff that I can import and/or copy/paste that would be useful? For context, it's a turn based grid dungeon crawling roguelite thing, so I don't need any 3D graphics or physics or anything. Just an easier way to have a bunch of menus and buttons that I can stick my game functions onto instead of wasting time re-inventing them all myself. I've never done proper game dev before, I don't have a CS degree, I'm a math dude who self-taught programming to do math research, so I have no idea what exists or is useful, and figured I'd ask here for recommendations before delving into google hell.

You could try libtcod (python 3), which I found on /r/roguelikedev. It sounds like it matches what you're doing.

GameMaker was good enough for Hotline Miami, so you could try it. If you're married to Python, you're stuck, as there aren't that many Python game engines that have enough plugins for you to skip the boring stuff.

Assuming you've been starting from absolute scratch, i.e. only the standard library, there are game engines that solve the question of "having a framework to click buttons in and have objects that move around". The problem might be that learning a game engine might be just as hard if not harder than learning a programming language.

Godot is one of the engines that people make 2D games with today.

I have to second this. Godot, for all that it infuriates me because it doesn't suit my very specific use-case, is actually a really good starter game-engine. It's lightweight, easy to use, and contains all the essential bits and bobs.

Working on a new project. There is an old out of print book about my family. "The [family name] and their kin". Old copies run for a hundred or more dollars on Amazon.

There is a free scanned version of the book too, but the scan isn't great quality. Adobe was able to figure out most of the words, but there are some glaring mistakes. Typically a mistake every 50 words or so, which is far too common.

I'd like to do a reprint. I just attended the annual meeting of the "[family name] society" and there was interest from everyone there in getting a new hard copy.

I've been copying and pasting the text from the PDF into a grok window and having it make corrections, re-italisize, and de-format the text. Might be another 20 hours to get it all converted.

I've looked up some print options as well and think with about a hundred copies I could get per book costs to $15-30. Depending on options I select. Color / hard back / images / etc.

have you tried using OCRmyPDF or Abbyy FineReader to do the first conversion? And then do the editing in docx/html.

I have not, I'll look into it, thanks for the recommendation.

What is this place?

This website is a place for people who want to move past shady thinking and test their ideas in a court of people who don't all share the same biases. Our goal is to optimize for light, not heat; this is a group effort, and all commentators are asked to do their part.

The weekly Culture War threads host the most controversial topics and are the most visible aspect of The Motte. However, many other topics are appropriate here. We encourage people to post anything related to science, politics, or philosophy; if in doubt, post!

Check out The Vault for an archive of old quality posts. You are encouraged to crosspost these elsewhere.


Why are you called The Motte?

A motte is a stone keep on a raised earthwork common in early medieval fortifications. More pertinently, it's an element in a rhetorical move called a "Motte-and-Bailey", originally identified by philosopher Nicholas Shackel. It describes the tendency in discourse for people to move from a controversial but high value claim to a defensible but less exciting one upon any resistance to the former. He likens this to the medieval fortification, where a desirable land (the bailey) is abandoned when in danger for the more easily defended motte. In Shackel's words, "The Motte represents the defensible but undesired propositions to which one retreats when hard pressed."

On The Motte, always attempt to remain inside your defensible territory, even if you are not being pressed.


New post guidelines

If you're posting something that isn't related to the culture war, we encourage you to post a thread for it. A submission statement is highly appreciated, but isn't necessary for text posts or links to largely-text posts such as blogs or news articles; if we're unsure of the value of your post, we might remove it until you add a submission statement. A submission statement is required for non-text sources (videos, podcasts, images).

Culture war posts go in the culture war thread; all links must either include a submission statement or significant commentary. Bare links without those will be removed.

If in doubt, please post it!


Rules


Recommended Posts And Communities

Recommended Realtime Chats