Okay, I generally side with *both* users and riggers because this cmo3 or not situation is mostly Live2D's fault but.

This has got to be the worst rigger take I've seen so far. If you can't afford to keep your clients' files safe by default, you should not be doing this job.
If you do not provide a cmo3 to users, it is your absolute prerogative to make the utmost effort to never, ever lose those files.

There is no possible excuse for losing paid client work like that. Ever. Period. That's a hill I will die on. This is the lowest possible bar.
This is literally Computer 101. You should have backups. You should have off-site/cloud backups. And you shouldn't charge people for it.

If you don't, you are not a serious professional in *any* computer-based field. This is a basic industry standard requirement.
That's like saying "I charge my users for the prorated cost of the computer I bought".

This expense is part of doing business. It should be built into your cost structure.
And this isn't even just about the cmo3 business. Being able to provide files again to your clients in case *they* lose them is a minimum courtesy service. Yes the clients should have their own backups, but why wouldn't you provide a failsafe? You have backups anyway, right?
The only exception to this rule I can think of is for people working in areas with massive project files (video, think 100+GB per project). And even then you should be keeping stuff backed up for free for a time period and disclose this guarantee.
It is a genuine *tragedy* for people to be unable to update your model because you lost the file.

People's models are their identity. Losing access to it for updates is a tragedy and something I would say isn't far removed from medical malpractice.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Hoshino Lina / 星乃リナ 🩵 3D Yuri Wedding 2026!!!

Hoshino Lina / 星乃リナ 🩵 3D Yuri Wedding 2026!!! Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @Lina_Hoshino

May 31
A lot of people aren't appreciating how weird and abnormal the Live2D situation is. Thread.

I make music. When I do a comm, the client can ask for stems, which allows them to remix or remaster the song part by part. I don't need to send them my project file and plugins.
When you commission model art, you don't get the raw working PSD file, the artist's brushes, or their editor settings, but you get a cleaned cut PSD file that can be rigged but also built upon for adjustments and additions if necessary.
When you commission a 3D model, you may or may not get a raw .blend file, but whatever final model file can usually be re-imported for adjustments or changes and additions, and different models can be merged together into one.
Read 11 tweets
May 31
I understand the riggers' perspective here because the project file has their workflow and settings; but

For a client, this is equivalent to buying a car you can't service or change any parts on. Right To Repair is a thing for good reason.
The bigger issue here is Live2D moc3 is a proprietary file format that has not had meaningful third party tooling/RE.

It's like the only options are you can't service your car at all, or the manufacturer gives you all their source code.

It doesn't have to be like this.
Live2D could easily fix this by allowing moc3 files to be imported into a new cmo3 file "as a black box", set up so that you can remove/hide ArtMeshes and build on the existing parameter inputs and physics settings, but not view/change the actual parameter rigs.
Read 7 tweets
May 23
TIL people are using crazy FPGA DMA attack stuff to... cheat in games.

Back in my day this was a fun attack vector for things like BitLocker and other secure systems...

Also... $6k???? You can do this for a couple hundred max, someone is making BANK here.
Kernel level anticheat is evil, but also, if you're running this kind of insane setup you kind of should expect it to stop working with any OS/driver update too.

If you're booting your OS from a fake evil noncompliant NVMe drive itself then... yeah you kind of had this coming.
TLDR Valorant isn't bricking anything, it just turns on a system security feature that makes these crazy fake NVMe drives stop working (because they don't follow the NVMe spec)... and I guess some people had Windows installed on them so it stops booting or something.
Read 5 tweets
Oct 17, 2024
Almost every thread about Rust for Linux ends up with someone saying "why not Zig instead"? And usually the answer is just "it's less mature" or "nobody pushed it".

I didn't know anything about Zig, so I decided to take a look today... and I'm not very impressed ^^;;
I learned that Zig does not have:

- Destructors
- Macros
- Lifetimes
- Operator overloading

Those are major reasons why I chose Rust for the drm/asahi driver...

It sounds like Zig is trying to be "modern C"... but the whole point of R4L is to not get stuck with C!
All those things Rust has that Zig doesn't are important for the things I'm doing.

Destructors/RAII are fundamental to how the driver tracks and cleans up firmware structures safely and reliably when needed. If I had to write "defer" everywhere it would be a bug-prone mess...
Read 14 tweets
Sep 1, 2024
Honestly, I'm kind of sad about Wedson leaving RfL. He developed a huge part of the foundation that made Rust for Linux possible.

I'll still work on DRM (except sched) and driver upstreaming when the core stuff is in place, but I don't know about other subsystems.
At the rate things are going, I wouldn't be surprised if upstreaming the drm/asahi driver isn't possible until 2026 at the earliest. I had hopes for things to move much faster, but that's not possible without active cooperation from existing maintainers, and we aren't getting it.
Reading upstreaming mailing list threads is painful. Every second comment is "why is this not like C" or "do it like C". Nobody is putting any effort into understanding why Rust exists and why it works. It's just superficial "this code is scary and foreign" type reactions.
Read 8 tweets
Aug 31, 2024
I think people really don't appreciate just how incomplete Linux kernel API docs are, and how Rust solves the problem.

I wrote a pile of Rust abstractions for various subsystems. For practically every single one, I had to read the C source code to understand how to use its API.
Simply reading the function signature and associated doc comment (if any) or explicit docs (if you're lucky and they exist) almost never fully tells you how to safely use the API. Do you need to hold a lock? Does a ref counted arg transfer the ref or does it take its own ref?
When a callback is called are any locks held or do you need to acquire your own? What about free callbacks, are they special? What's the intended locking order? Are there special cases where some operations might take locks in some cases but not others?
Read 23 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(