oh, there was new releases, then i go check how it works in them
Well, latest 0.57 looks very broken for me
At the moment you try to open that menu with quick settings, like range, offset, etc in fullscreen - it opens “hidden”, so i can’t see that setting window. But at the same time - it count as open, so main video windows became uncontrolable. There is no way to pause\stop\close\un-fullscreen it, until you go Alt+F4 and close whole software with it
I’m not sure what that would have changed between 0.5 and 0.57. Full screen is broken in more than one way. It needs to be redone completely but I dont recall changing it recently.
it also gives me this at almost all VR AV1 videos, even if i had KL codecs before, and updated them to latest after seeing this error. It doesn’t go away
Guess i go back to 0.47b again, all above it has way more problems(
You checked “Use the media back end of the OS” on the system tab? AV1 is NOT supported in v0.5b + default codecs. I hope this will change soon. It will work in XTP Web though. It should also work if the above option is checked.
well, i tried both check\uncheck on this option - changed nothing
funny enough 0.5b support it, but 0.57 isn’t
You restarted the app? It changes the backend on app load.
I did…
Just go back to 0.47b again i guess, it’s stable
I’m sorry, the video is playing normally while I’m running, but my OSR can only run in the stroke direction. Do I need to change any buttons to support multi axis script playback .
But when I drag them in the motion button, they can swing normally again.
Can you help me clarify my doubts
I think I need more information but ill just give you an overview.
Funscript:
The original 1.0 funscript standard is:
videoname.funscript
videoname.mp4
Multi-funscript (MFS)
videoname.<channel>.funscript
// Where <channel> = the channel name for example. roll would be videoname.roll.funscript
videoname.funscript
videoname.mp4
If the files are named according to the above format, then XTP will just load them.
Note: There is a bug where it doesnt see it on first scan. If this happens reload the library. If it still has issues try updating the media item metadata by right clicking it on desktop and using the context menu in web.
Funscript v2.0 (SFMA)
XTP greater or equal to v0.55b. You can also download the funscript 2.0 version here on eroscripts and all channels should load from a single funscript file. (There is a setting you may need to change on eroscripts to set 2.0 as the default format. v1.5 is NOT SUPPORTED IN XTP).
Random motion:
If the media does not have any the multi axis scripts listed above, checking the random motion checkbox on the motion tab will add motion. Below is an example of random motion on the roll axis.
Theres a few other settings that affect the motion.
Link:
If you want say the pitch to match the stroke actions 1:1, you can check link to script and select Stroke. This will move the pitch the same rate to the stroke.
Speed:
If Speed is enabled you can set the value to be a multiple to what ever the current speed of the linked script is. In other words making it move slower or faster than the linked funscript speed.
Hope this helps!
Thank you for your detailed response to my question. After using random motion to control its roll and twist, it was able to move normally. Perhaps the script I used did not include these directions of motion, but I included them when running the script in Multifunplayer, or perhaps the software itself enabled this feature. Anyway, this issue has been successfully resolved. Thank you again
1 Like
If you scroll down to the bottom of the motion tab, youll find the channel map.
The script loading is controlled by the Track column. So in this case, TCode channel R1 is linked to roll so:
videoname.roll.funscript
will load and send commands to R1 on the tcode device.
The scripts have to have the videoname.<track>.funcscript for XTP to see load them.
I did end up figuring out this issue. Seems that if you run the application on Wayland it’ll cause this artifacting.
I fixed it by running the program in the terminal with “QT_QPA_PLATFORM=xcb [application path]” which I believe forces QT to use X as it’s platform. After that the program works just fine.
Oh odd, Im running on wayland in Debian 13.
Maybe Debian 13 is automatically running it through X? No idea, the same issue happened for me on Bazzite and CachyOS. Both were fixed with the terminal command I used.
1 Like