Multi-Element Stroker / AI / Funscript / TCode

I dont agree because I still dont understand, you are explaining your concept device from your POV so you are assuming a lot, but we dont know anything about it.

If you want something to happen for 3 seconds, then just script the actions.

Ah, maybe when I say ā€˜length’ you are thinking time, when I mean physical contact length.

Regardless: I have enough info for basic testing now and will come back when I have a prototype to demonstrate. Thanks for your time so far.

For scripting, seperate script files is generaly the best. It has the best backward compatibility, and most tools can already make these.

I can understand why you want to merge them (as collisions should be considered in scripting so they dont happen). But even this isnt realy needed as there are other tricks you can use here.

First of all: why not use .zip to pack 3 scripts together? Unzipping and loading the folder is trivial these days.

And second of all, if 2 scripts would collide, you can calculate exactly when, and just convert it so both have that as mid point, and beyond that swap the scripts around (before L0 uses lin1 and L4 uses lin2. after that node L0 uses lin2 and L4 uses lin1). Next collision they swap back. It ensures the most upper section uses always the most upper scripting sections. This makes it even easier when things get swapped around as you no longer need to care about it when scripting. It handles it for you.
Being a plugin to handle this at first is fine. For devices like this its even recommended to have it that way.

There realy is no need to expand funscripts here. At most metadata as support can be done, which funscripts can already hold. But OFS doesnt support that and is still the #1 tool. And i realy recommend sticking to formats it can handle.

Best is therefor a seperate metadata file, which you can be sure of almost nobody is going to care about.

No matter that your device can do 2 sleeves at once, its still not going to even be remotely the same as the real thing. And most people that use these tools are very well aware of that. They just want a good sensation.
Being the first allows you to set a standard on it though, so at least use that power. You can already define limits and standardize a few things, just because of having no competition. Just dont edit the existing standards, they are already that far set in stone that it wont happen.

Hey SomeoneRandom, thanks for the thoughful reply.

You’re right, I was wanting to create a standard for this kind of device, obviously I should have realised it’s necessary to prove one’s worth first. I’ll just bastardize whatever is necessary for now. Great that MFP is so customizable.

About OFS: I don’t expect humans to make scripts for this device, it needs too much data. I’m sure that the AI will continue to improve drastically over the coming years.

I posted quite a few times with my ideas for devices and TCode long before I actually built something and none of it went anywhere.

You’re absolutely right that you need to build something first. And then look and see what resonates with people.

You underestimate humans.

Some videos are highly popular that making the script by hand means at least 100 people are going to use it as intended. Note that some scripters already handcraft 9 scripts for 6 axisses, suction, vibration, and rotation. Just 2 linear axisses is just basic compared to that.

Especialy when it involves animated content handcrafting becomes even more common, as these often do repeat the same movement multiple times making copy paste in scripts viable. With high demand videos (Maximus Jandari) which often involve a multi linear axis motion, i do even expect these to show up within a week.

And even then. While AI exists, their scripts are often just a good starting point, but far from realistic. They often add micromovement that is actualy counter productive to the sensation. Cleaning this by hand is very well doable.

The scripters arent the limitation here.