Correct but we as in YOU and I need to have standard names so we know what to expect. As does the estim need its names.
I would suggest trying to find overlap where there could be like with some of the the vibe tracks.
And yes we map them to TCode axis but that doesnt imply a 1:1 relation. the vib funscript could map to the L0 channel if someone wanted it to. (I actually do this all the time in XTP with my TVibe, well in a round about way.) Our applications map these funscripts to TCode. Thats why they exist in the first place.
Ive always been against using TCode channels in the funscript format. This is why XTP doesnt support videoname.L0.funscript by default.
Edit: As a somewhat unrelated note. Ive noticed vib and vibe. Ive been using vib. I dont know why but I think the existing scripts are using vib as well. Using vib would save some backporting headaches but I do like vibe better. Not sure if I like it better enough to go through the pain to rename it…
Ya I made a post about the extensions when we first created the multi script system but other than that its been the wild west. The post was pretty premature to what is currently out there now.
Allot of those are just file names and not targeting multi axis devices im pretty sure.
Its kind of been up to the user to rename the scripts to what the player accepts.
Hiding these values inside the script will obfuscate what would normally be obvious with the file name.
Not sure how to remedy that exactly. I suppose the user will need to look at the included tracks when downloading assuming those are printed out for the user near the down load link.
All of those values in your list is going to make your automated scripting more difficult. May want to add a toggle for sfma parsing on the upload if you can.
I don’t understand the discussion around the standard names.
Scripter makes multi axis script and names the funscript files however he wants.
Scripter uploads the files to eroscripts and eroscripts automatically merges them into one file based on the “base” funscript (video.funscript)
Eroscripts generates the heatmaps for the merged file, the heatmap can either use the track name to display instead of L0/R0 etc. (the font size will be different for different track names), or just show the full file name before merging in the top portion of the heatmap (while removing the current colored L0/R0 etc. section)
I suppose that was more for you and I. If Eroscripts/Dimava wants to keep a track of valid names to simplify the automation is up to them.
But we as funsctipt mappers need specific names to know how to map to what in TCode by default. I will not leave channel/track setup to the user. Asking them to maintain the file names is already too much as you can see from the above list.
So I guess basically I was saying, I’m leaving the track names the same as they multi file system.
Easiest path to migrate from.
Also if Ero wants to enforce a name policy to keep things standard across multi-axis devices they could. It would help prevent the mess above. I try to enforce it with XTP but I do allow custom channels/tracks if the user wants to change it for some crazy reason.
Its better for us and the user if we keep things nice and tidy so its mostly plug and play.
Some of my users play with multiple e-stim boxes at the same time. They copy/rename some of the funscripts (video.alpha.funscript into video.alpha-prostate.funscript) with minor edits (invert) so they get played on the second box.
Just pointing this out to show that there can’t be a pre-determined list of valid track names. This is before we get into the issue of development of new devices. Recommendations to use specific identifiers for specific devices are fine, which should be copied from existing software.
These scripts have to be routed to the device hardware somewhere therefor there has to be a predetermined list mapped list somewhere along the chain. Just the further back you go the bigger that list will grow and harder to maintain.
Also the player could more efficiently handle that functionality with multi device logic.. Instead of copying scripts, setup multiple device/script maps that link to each other. Read in the script once and process it according to the map. No need for tons of special script names and wasted diskspace.
Which was a good decision at that time. And these names have proven that they are effective over time. No need to change those. If we see pitch, we know which axis it is. Linear, pitch, roll, twist etc are names that are easy to understand, thats why they are effective and ensuring that these are standardized is a good thing.
Changing it now would backfire by adding confusion and as a result often wrong working scripts. Its not worth the hassle.
Hoewver, since you cannot predict the future, having flexible naming is fine. What if your device has a new feature to use. Then its fine if you create a name for that (sure, it might still get renamed later on, but thats the early adoption downside anyway). So yeah, if someone wants to use the axis ‘foobar’. let them. If its a meaningless axis the community will rename it anyway. Funscripts are easy to modify.
What i do consider the difficult part is ensuring that new devices have a proper way to map old scripts onto them, while being able to separate newer scripts. For this we should look towards a standard that works. If a device gets a 2nd linear up/down motor. We dont want any other axis to conflict. So on this, any different axis shouldnt get any overlap with any other axis. T-Code already does this, but since that is a mapping thing, we can handle this fine (linear2 can be mapped to L4 fine, just like mapping vib1 to v0 and vib2 to v2 is easily managed).
And to assist this: a look back sort of system is important and standardized. And for this we can have a very simple and basic one that essentialy already has been placed in the standard:
missing information gets assigned a default:
No axis name → linear
no motor number → 1
Overlapping names → most ‘targeted’ name wins (linear1 beats linear).
Already existing motor numbers → take next (if linear1 exists, linear points to linear2).
To clarify. If a device already has the 2 axises in place like a roll2 and pitch2, but has no linear2 axis, this will point to linear3 to still target an existing device. Its not strictly the next number, its next available
I think that way all flexibility should be managed, as in the end the final configuration of devices gets performed within the playback tool anyway. And i think we can define a standard quite easily: Any information that is omitted gets extended towards a default, which is predictable.
Its not foolproof, but that is near impossible. If someone uses 2 devices like for example a handy with dildo adapter and osr2. Yet the osr is mapped to device 2. It wont work as well as when the osr is device 1. Thats a user error we cannot circumvent, What we can do is making it easy to map these devices around so they do match what is desired. But this is what the playback tool needs to manage, the funscript should be a dumb format that has no device awareness.
How about when the user downloads a merged script, the scripts are zipped on the site and are sent to download? Users still don’t get to upload zip - they are created by the site software.
Unless a scriptplayer can use it directly, it has little value to download a zip except saving a little bandwidth. Generated is ofcourse better since it at least avoids the security issue.
But if we need to unpack the zip afterward, i dont see any benefits over the packed funscript file we have now, although, i still seem to go for the separated files even with that option.
The advantage of the zip is that you get one file for players that support it and very little code needs to be added to support it because the underlying structure of one-funscript-per-axis is unchanged.
For legacy programs, one can unzip the files and no code changes are needed.
With the multi-funscripts-in-one-funscript proposal, a little bit extra code needs to be added, but it simply wont work in legacy programs unless we create some special conversion tool and educate users to do that.
This is much more work for the developers and users, for the same potential benefit of having a ‘single file’ for multi-axis scripts in compatible programs.
I think all the scripts are made for a specific device
I would love to have an device-independent format, but it would me significantly different from Funscript
Device independent format requirements draft
Channels are grouped into groups. So the problems of “different devices” or “variants” does not appear. Multiple groups may have same channel, plain or postprocessed.
Linear channels are up, right and forward. Rotary are right, forward and clockwise. Right and forward L/R axes are “paired”.
IMO this matches man POV which it the thing that is generally scripted
Zero position is bottom neutral
Linear axes are scaled to up axis range, making them roughly -25~25
Rotary axes are scaled in degrees, making them roughly -20~20
The disadvantage of zip is that you need to add a whole new dependency to make it work. Currently all you need is plain JSON.
The amount of code change for multiaxis file is way smaller then for adding zip support (tho it heavily depends on the language and the model). Roughly it’s adding “for each valie in channels parse it same as an extra file”. Just the code to scan for the extra files is larger then this.
I don’t care about users of legacy software, I care about my bros who ask me “hey, what’s up with your online merging tool, I wanted to use it to merge some scripts and it seems to be down”
As a happy @bunjavascript user I wholeheartedly agree that better DX/UX is way more important for me then supporting anything legacy All the developers are already here (now when you came here lol) and I define what users get to download from this site (currently it’s SLR format because MFP supports is and download-files-one-by-one-but-with-single-click because everything else supports it and it’s waay better UX then having to click on 3-7 scripts
I think there’s no real point to discuss legacy apps further, I’ve make this thread specifically to invite current SOTA player devs here so most of SOTA player are updated. Can’t do anything with legacy anyways. The two devs here cover MFP and that cover 95+% of multi-axis users on this site (according to the latest poll)
The only legacy I somewhat care about is backward compatibility with single-axis, mostly because it’s orthogonal to multi-axis and has completely different list of players (that don’t support multi-axis anyways so won’t be a problem)
Please do list the whole list of multi-axis programs tho, the only one that came up till now is OFS
The list I know and use is: OFS(archived, I’ll fix it I suppose), MFP( @Yoooi please review the last draft in this massage above and tell me if you’re fine with implementing that ), XTP( @Khrull ), EDI( @dimnogro please review the last draft in this massage above and tell me if you’re fine with implementing that )
Now I know there is Restim ( @diglet please tell me if you don’t mind changing the username to diglet48 or something )
Is there anything else and someone we should call here?
All the software discussed already has a dependency on zip, except OFS.
I can’t speak for other software, but my software makes the assumption that 1 file = 1 axis. I’m not saying it would be difficult to add support for multiple axis in a single file, but it does mean that all future applications need to support both variants.
If that’s what we decide upon, that’s fine.
I don’t care about users of legacy software, I care about my bros who ask me “hey, what’s up with your online merging tool, I wanted to use it to merge some scripts and it seems to be down”
That’s why I’m proposing a solution that does not depend on online merging tool.
As a happy @bunjavascript user I wholeheartedly agree that better DX/UX is way more important for me then supporting anything legacy.
with supported software there is no difference in DX/UX between your proposal and mine. With legacy software, my solution results in significantly improved UX.
All the developers are already here (now when you came here lol) and I define what users get to download from this site (currently it’s SLR format because MFP supports is and download-files-one-by-one-but-with-single-click because everything else supports it and it’s waay better UX then having to click on 3-7 scripts
I don’t think MFP supports the proposed format because of the axis names, and everybody seems to agree the SLR format is bad because of the axis names.
I don’t think you missed any major stakeholders, but there are a few tech-savvy users (including myself) that have scripts that post-process funscripts and split out other funscripts, some of which are not distributed to the end user. There is are also some multi-axis scripting tools for blender. These scripts would require some updates.
For estim, particularly when it comes to the volume, there are cases where 0-100 is not enough granularity. The format should support ints and floats for the position. I don’t particularly care if OFS supports this or not, it likely is only useful when generating scripts.
What is the recommended behavior for script players when:
There are multiple funscripts video.funscript, video.twist.funscript where video.funscript is marked as V2 but does not have multiple axis.
Same scenario as above but video.funscriptdoes have multiple axis.
What is the recommended approach when distributing scripts for separate devices. For example a slower script for the handy and a faster script for SR6. Is it to download only the script provided for your device?
V1 format for Handy merged with V2 format for multi-axis I think
That’s the main reason I want to keep root actions for main axis and make it overridable with channels.stroke
Handy perfectly works with that format afaik
As for SR6 vs OSR2 vs SSR1-Twist I guess we’ll just assume all scripts are made for SR6-Twist and that’s it
Maaybe it would make sense to add metadata.devices for assumed used device but I suppose no-one will use it anyways cuz all the scripts are made for the SR6t as the common divisor
(The only incompatible case is OSR2 with modified scale, but well, who ever uses the 15+/25+ tilts anyways)
Off-topic: @Khrull does your OSR2 firmware have linear R mode where R angle does not depend of L0 position? (it’s 25 on top/bottom but around 45 in the middle iirc)
