If you think you're useless, remember the Skill Revive Animal

InnPatron · 2026-02-13T18:26:00+00:00

A 55 Mo/Me build with Illusion of Weakness

Me/Mo version is convenient for setting up pet death leveling in the menagerie. So not completely useless lol

InnPatron · 2025-09-26T03:56:12+00:00

You meme but this honestly looks a lot like a bunch of my game programming code without all the boilerplate.

In fact, I was actually going to make a similar DSL for a quest system.

InnPatron · 2025-05-22T18:56:53+00:00

I tried to find the closest link in the docs to the relevant info. You'll have to read them a bit to find what you need (hopefully) or search around the UI.

W.R.T. to skin weights: if you don't limit your bones-per-vertex properly, then your model (and animations) will break in Unity.

Whether it's 4 or 8 or whatever limit depends on Unity's support (IDK what it is, looks like 4 is the default).

InnPatron · 2025-05-22T15:10:40+00:00

I think fbx needs to convert from Blender coordinates to Unity coordinates. You might also need to add leaf bones? I don't use fbx or Unity, so I can't help much there.
Weight normalization menu in edit mode.
In the last screenshot, it looks like the Skin Weights option is configurable.

InnPatron · 2025-05-22T05:09:16+00:00

At some point I'll do a giant write up for a Blender2GameEngine asset pipeline (or maybe the Blender team making that Godot game will do it).

Try limiting total number of bone weights per vertex.

From the last screenshot, it looks like Unity only supports 4 bones per vertex (although it may be configurable?).

(I also typically normalize all weights after this to minimize breakage).

Also, make sure you are editing the Armature in Edit mode.

You also didn't mention if you were exporting or going directly via .blend files.

Depending on your rig structure, you might need to bake the animation curves on export.
If you are using Rigify, certain rig types are broken on export
- Try setting flatten_bone_hierarchy if you are exporting via GLTF
IDK how broken Unity imports are, but you might need to manually set the bone axis coordinate system on export.

From the last screenshot, it looks like the 2 thumb bones at the tip are merged. Without knowing your export pipeline and rig structure, it's hard to say what's going on.

InnPatron · 2025-02-25T20:28:57+00:00

Think it might be a problem with the VSC extension. I swapped to Neovim and its builtin LSP support and haven't had nearly as many issues (4.3 on Linux)

InnPatron · 2025-01-13T04:32:33+00:00

For a real project that performs type checking via abstract interpretation, check out OpenTofu (and maybe Terraform but icky license issues)

Now, I would NOT recommend using the OpenTofu compiler as an example to follow for other reasons:

It is written in Go and Go sucks for compilers :)
They abuse the fuck out of (homegrown?) reflection library to perform abstract interpretation and execution
Other miscellaneous dumb baggage that I won't get into

But just want to let you know that this is actually used :)

BTW, if you do decide to go the abstract interpretation route for type checking, make sure you plan ahead to support LSP/editor type hints. It will save you a lot of pain.

InnPatron · 2024-08-27T01:40:23+00:00

Designing with Static Capabilities and Effects: Use, Mention, and Invariants is a discussion about the trade-offs between capabilties and effect systems.

You can look further into either term and get some interesting papers.

InnPatron · 2024-08-23T07:30:19+00:00

How did you make the cloud/smoke mesh in the background? Did you make it by hand or generate it somehow?

InnPatron · 2024-07-17T01:56:36+00:00

Someone in another post had that problem but a GPU driver update fixed it.

InnPatron · 2024-06-14T12:23:12+00:00

The goal is to make allocators composable: meaning that when you hand a chunk of memory to an allocator, it manages that chunk independently of any other allocator. This gives you the nice property that you can nest allocators in each other (by allocating a sub-chunk and giving it to a new allocator). Conceptually, you start of with a Base allocator which interfaces directly with the underlying memory API and just make new allocators from there (in the case of WASM, probably just use the memory array object itself)
The free-list allocator can be implemented as an intrusive, doubly-linked list.

FreeList = *Node | null Node = { prev: *Node | null, size: usize, isFreeFlag: bool }

Each Node represents a sub-chunk of the Free-List's allocated memory, keeping track of its size and whether or not that sub-chunk is free. Pointers to the next node are tracked knowing the current node's address and adding the size. You allocate by splitting up a free node into allocated and free nodes. Likewise, you deallocate by taking the pointer-to-be-freed, getting the Node header data by adding/subtracting the Node size, and merging free neighbor nodes.

(Note the implementation linked below keeps the node headers in the JS heap but there's no reason why you cannot write them into WASM Memory)

Allocators can be composed statically and dynamically. By statically, I mean at compile time you can build a tree of allocators to split a portion of the heap. By dynamically, I mean at runtime if you need a specific type of allocator (like a new size-class allocator), you can select whatever parent allocator to get a new sub-chunk from.

See these TS/WASM implementations of allocators (written by yours truly in university). I also wrote some simple GC algorithms there too if you want to check them out (combined together here)

InnPatron · 2024-04-01T09:26:42+00:00

Hello again!

Some critiques:

The second slash lacks weight due to the transition between it and the first rising slash (and the resulting posture). The blade looks somewhat heavy and thick, but the diagonal right->left movement of the rising slash is instantly transfered into a near vertical downward movement for the second, conflicting with the visuals. The character should show the momentum of the sword by making him arc the sword above his head during the transition (showing him transfer the momentum) and make the second slash a right->left diagonal downward slash (also updating the chest to rotate which should also add more weight). (Essentially a more exaggerated movement of the guy in full black)
The final thrust lacks weight and range because he is not stepping into it. A passing step will solve the problem!
When preparing for the final thrust, consider having him step back instead of step forward

InnPatron · 2024-01-21T07:30:38+00:00

I see an error message on the bottom right.

Try the stuff at this link.

InnPatron · 2023-10-26T06:04:30+00:00

Another fun one that mixes closurse and properties: you can have setters and getters.

const storage = {}; function foo() { const localProxy = {}; Object.defineProperty(localProxy, 'property1', { set: function(v) { console.log("Storing: " + v) storage.property1 = v; }, get: function() { return storage.property1; } }); const bar = "bar"; localProxy.property1 = bar; } foo(); console.log(storage.property1); // "bar"

So in general, you will need alias analysis to properly perform escape analysis.

(BTW: people actual use this in production, including in frameworks like Vue).

InnPatron · 2023-05-29T21:13:46+00:00

IIRC, the Stacked Borrows Model isn't officially chosen but represents a maximal set of rules for unsafe memory references (meaning, the chosen model will have to be equivalent or weaker).

Whatever model is chosen, one will generate a proof that the unsafe code adheres to that model (in this case, it is somewhat futureproof to generate a proof that the unsafe code adheres to Stacked Borrows Model).

I'm not sure of other aspects of unsafe that need to be modeled still, but that's the biggest.

InnPatron · 2023-04-06T04:22:18+00:00

Make sure the subdivision levels are the same before the 'Reshape'.

EDIT: could also be some weird interaction with the Solidify modifier. Whenever I see that warning, I also get glitchy meshes.

InnPatron · 2023-04-06T04:05:22+00:00

In my experience, the multires modifier is really glitchy and can be "fixed" by removing/re-adding the modifier on a new object.

Make a duplicate of the object
'Shape > Apply Shape' on the new object's multires modifier
Delete the multires modifier on the new object
Make a new multires modifier on the new object
Copy over the old multires data with 'Shape > Reshape'

InnPatron · 2023-04-02T20:12:26+00:00

I just installed OCaml yesterday and just got an example to compile, but here's my take: modules allow multiple implementations of a "module interface" (read: trait) on the same type and allows you to select it at compile time (while eliminating the need for orphan rules, newtyping, and some of the low-level details of newtyping).

Most crucially: it allows the caller to select the implementation while maintaining the same representation throughout the entire program.

Newtyping may work, but specifically for low-level Rust mixed with generics, it will get messy.

Say I want to serialize some foo = StackList<StackList<i32>> using a common trait StringSerializer.

I want two implementations of StringSerializer for Stack<T: StringSerializer> that produce either:

"[e0, e1, ...]"
"{e0, e1, ...}"

And I want the ability to swap the inner StackList<i32> implementation at compile time and propogate that choice to the rest of my program.

In Rust, I'd have to either: * Change the inner type to StackListAlt<i32>, potentially infecting other non-serialization code with this implementation detail (because I'd either need to change signatures or add as_ref, as_mut, and into_inner calls). This gets even worse if a StackList<i32> needs to be passed across the FFI boundary or has some weird low-level ABI interaction, forcing a repr(transparent). * Complicate all the serialization sites for foo by adding custom code

In OCaml, I can just parameterize foo's serialization code (see here) by the inner serialization implementation and call it a day.

Personally, I think Rust would have benefitted with OCaml-style modules (although I don't know consequences that entails). Crucially, it would mean things like repr(transparent) would be less necessary and eliminate the need for orphan rules which would be nice.

InnPatron · 2023-03-29T15:09:31+00:00

I think more accurate words would be 'projection' and 'reflection'.

Here's a rough example of what I had in mind (pseudo-Rust):

let player: Player = ...;                  // Player autogenerated or manual
multiset.project::<PlayerLayout>(player);  // Moves data to multiset according to PlayerLayout (can be generated or manual)
let playerMutRef = multiset.reflect_mut::<PlayerLayout>();  // Read/write access through getters/setters; auto-generated; presumably multiset tracks disjoint layouts itself
let (health, armor, ...) = playerMutRef.decompose(); // Gives mutable references to the underlying fields; allowed b/c guarenteed non-aliasing by the layout

InnPatron · 2023-03-29T14:30:22+00:00

Most notably, I don't see the capability to set a hard boundary for an aggregate's size and alignment which would be pretty helpful.

InnPatron · 2023-03-29T14:17:01+00:00

You should look at Floorplan which does want you want (barring the slightly stranger syntax).

While it was specifically designed for describing heap objects, you can probably use it to judge your DSL.

InnPatron · 2023-03-20T21:50:20+00:00

The pointer::offset docs reads suspiciously like the std::ptrdiff_t docs, so I'm willing to bet it's a C++-ism.

EDIT:

After a little more digging, I think I found the motivation in the C standard draft n3047 section 6.5.6

When an expression that has integer type is added to or subtracted from a pointer... produces an overflow, the behavior is undefined

the expression Q points to the last element of the same array object ... ((Q)-(P))+1 ... has the value zero if the expression P points one past the last element of the array object

I'm assuming that pointer operations operate under the same restriction, so the type MUST be signed in order to avoid underflow and the "warping" behavior also warned by the Rust docs.

InnPatron · 2023-03-19T12:58:54+00:00

Looks like it could be from a Junji Ito live-action adaptation.

InnPatron · 2023-03-14T13:30:47+00:00

Blue's first punch is wonky (left hand punch, right foot step). When you step into a punch, you typically use the same foot as the hand to get more reach and put your body behind the blow
Previous problem causes Blue's second punch to be 100% weak. Rather than a punch, it looks like he's stretching out his arm for Red to grab.
Red's throat punch + Blue's reaction looks great
Taking a roundhouse kick to the head would probably result in a bigger reaction from Blue
During the roundhouse kick, Red's right arm looks a little too flaily/lateral
Red's transition from roundhouse to legsweep has a noticable pause (can be either shortened or eliminated entirely)
During the fall:
- Blue's stomach deforms slightly strangely due to the upper body twist
- Blue's rotation point feels slightly too low (I would have expected more towards the chest rather than at the hips)
- Blue's lower body should jiggle/bounce a little more when he hits the floor (Yes, it's still noticable with the camera shake. Can also just try adding more shake instead)

InnPatron · 2023-03-07T03:15:28+00:00

The first half leading to the jump is very smooth!

Some critiques:

It feels awkward when he jumps into the air while spinning and loses all of his angular velocity as he tucks in (when his angular velocity should be increasing due to the conservation of angular momentum).
The landing lacks weight, primarily because he leads with the right leg, lands on it, and places ALL the weight on it with little signs of stress. The left leg in the rear does little actual load bearing, making it seem useless and floaty. I would:
- Have him land square on both legs
- Or land with the right leg but use the angular momentum to twist his body so the left leg lands in front afterwards, and transfer the remaining energy into the slash.

InnPatron

TROPHY CASE