• Hi Guest!

    Please be aware that we have released a critical security patch for VaM. We strongly recommend updating to version 1.22.0.7 using the VaM_Updater found in your installation folder.

    Details about the security patch can be found here.
ToySerialController+VAMLaunch

Plugins ToySerialController+VAMLaunch

Then I suggest you delete the default.json config and reset all settings. Some settings when set to min/max in combination with other settings may not be compatible and simply just not work.

So i finally think i understand what i may have done wrong.. in the notes you have you said DONT add the VAMX_Launch folder just the install and since i upgraded top V3 i most have done that.. Then i had to remove the default and do a HARDRESET and a Setting Reset and it now works now.. thanks for the help.
 
I am not sure if intended or not, but i found out that the fps has a direct impact to the detection. a 30 fps scene will result in basically the worst detection, with jagged movements and threshold detection, while a 90 fps scene will have same jagged movement but better threshold detection
 
If anyone has been trying to create buttons and sliders that can adjust this in a scene, @everlaster has a great plugin that you can use. BUT in order to make it work you will need to overwrite the toy's plugin with the following two files (everlaster made these revisions).

If @Blazedust wants to push a quick official update that would be awesome; otherwise here are the edits as per everlaster's instructions:

To the plugin.cs file:

1. Added Line 13; This line allows the script instance to be referenced anywhere in other files so we can register the parameters.
public static MVRScript Singleton { get; private set; }

2. Added Line 31; Without this the Singleton will be null and cause an error
Singleton = this;

To the UIBuilders.cs file:

1. Added line 17 to register popups as triggerable
Plugin.Singleton.RegisterStringChooser(storable);

2. and sliders, line 71
Plugin.Singleton.RegisterFloat(storable);

3. and toggles, line 104
Plugin.Singleton.RegisterBool(storable);

Making those edits will expose all the Toy plugins for scene triggers!

Thanks a ton to @everlaster for working directly with me to solve this!
 
Last edited:
Hey y'all! I have spent the past 2 weeks trying to figure out how to connect my kiiroo keon. When the tutorial says "Step 6, open the game, use ToySerialController+VAMLaunch" where do i find that icon? I looked through all my files/app data and cannont find that application/executable. Please help. Is there like a zoom share my screen I can do with someone?! I'll cash app you! I'm tryin to bust nuts out here yall! Will be reposting in a couple spots plz dont flag me
 
Hey y'all! I have spent the past 2 weeks trying to figure out how to connect my kiiroo keon. When the tutorial says "Step 6, open the game, use ToySerialController+VAMLaunch" where do i find that icon? I looked through all my files/app data and cannont find that application/executable. Please help. Is there like a zoom share my screen I can do with someone?! I'll cash app you! I'm tryin to bust nuts out here yall! Will be reposting in a couple spots plz dont flag me

You're willing to pay money for this tech help?
 
If anyone has been trying to create buttons and sliders that can adjust this in a scene, @everlaster has a great plugin that you can use. BUT in order to make it work you will need to overwrite the toy's plugin with the following two files (everlaster made these revisions).

If @Blazedust wants to push a quick official update that would be awesome; otherwise here are the edits as per everlaster's instructions:

To the plugin.cs file:

1. Added Line 13; This line allows the script instance to be referenced anywhere in other files so we can register the parameters.
public static MVRScript Singleton { get; private set; }

2. Added Line 31; Without this the Singleton will be null and cause an error
Singleton = this;

To the UIBuilders.cs file:

1. Added line 17 to register popups as triggerable
Plugin.Singleton.RegisterStringChooser(storable);

2. and sliders, line 71
Plugin.Singleton.RegisterFloat(storable);

3. and toggles, line 104
Plugin.Singleton.RegisterBool(storable);

Making those edits will expose all the Toy plugins for scene triggers!

Thanks a ton to @everlaster for working directly with me to solve this!
That is a clever edit, I might just do that at a later time.
 
Blazedust updated ToySerialController+VAMLaunch with a new update entry:

ToySerialController+VAMLaunch (update) v.11

Added edits suggested by ajtrader23 https://hub.virtamate.com/threads/toyserialcontroller-vamlaunch.14653/post-142113 , exposing a lot of settings for other plugins. Also added actions for other plugins to start/stop the device and to be able to save/load configs.

Updated default config values and files to be a bit more agressive.

Added optional default configs that you can download and extract into your VAM install.

Read the rest of this update entry...
 
I have an idea, @Blazedust and @everlaster because of the new update... maybe you guys can help figure this out.
With a few changes, I'm pretty certain that this plugin could be used to keyframe toy motion in a very similar manner as funscripts. I think the key to this might be in the "Override Value" variable. Now that the plugin's values can be controlled by external triggers, it's possible to keyframe the L0 Override slider in Timeline. If the toy followed this override value with decent accuracy, I could easily make it follow the thrusting in a mocap animation just by inputing some Timeline keyframes. That would be simply incredible!
The problem is: The Device Simulator (as well as the device) doesn't maintain the input motion, and I don't understand why. It always returns to zero afterwards.
It should be able to stop at different points of the stroke and stay there, or change direction. This can be observed in the behavior of funscripts, and also by changing the device Min and Max range while it is oscillating.
Any idea why the plugin behaves this way, and if there's a way to fix it? Or maybe you can think of a better approach to the idea of keyframing positions? I've been hoping for something like this for years. If it worked, it would be a huge game-changer!
 
Last edited:
I have an idea, @Blazedust and @everlaster because of the new update... maybe you guys can help figure this out.
With a few changes, I'm pretty certain that this plugin could be used to keyframe toy motion in a very similar manner as funscripts. I think the key to this might be in the "Override Value" variable. Now that the plugin's values can be controlled by external triggers, it's possible to keyframe the L0 Override slider in Timeline. If the toy followed this override value with decent accuracy, I could easily make it follow the thrusting in a mocap animation just by inputing some Timeline keyframes. That would be simply incredible!
Here's the problem: The Device Simulator (as well as the device) doesn't maintain the input motion, and I don't understand why. It always returns to zero afterwards:
View attachment 318458
It should be able to stop at different points of the stroke and stay there, or change direction. This can be observed in the behavior of funscripts, and also by changing the device Min and Max range while it is oscillating.
Any idea why the plugin behaves this way, and if there's a way to fix it? Or maybe you can think of a better approach to the idea of keyframing positions? I've been hoping for something like this for years. If it worked, it would be a huge game-changer!
For linear toy devices (which this plugin is made for) it tries to predict, based on 1 value (current axis input), the distance, speed and where to stop (min/max) based on earlier strokes. This works decent enough in most scenes. The override value just overrides the current axis input which drives this whole mess :)

Way back before timeline and when VamLaunch was new, I did some proof-of-concept code for keyframing animations. It had accuracy but was a lot of work setting up keyframes manually and with a VAM crashing constantly back then I gave up that path. This was before TimeLine and .var packages was a thing.

It all depends how much data you want to feed the toy. While position is one parameter, speed is another. At the end, I think it's easiest for the animator to just have to worry about the position.

The keyframing basically consisted of a position+timestamp. Where in the animation(time) would the toy end up (position). The rest could be derived based on this information, such as the speed.
One could perhaps think of a way to have 1 slider value controlled by timeline that when changed instantly (Curve type: Constant) would represent the next position. Now, it can't be a position where you want the device to be as it can't travel instantly at the speed of light to that position. But having a position representing a future timestamp with a well-known time offset. With a well-known time offset for the future position then speed could be calculated and distance for each new position where the device should move to next. Tricky, but would certanly work.

Do you think it's reasonable to set position keyframes like one second ahead of time? Perhaps it's possible to do in another timeline plugin instance on another atom that you can keyframe and set position based on the current animation and then you cut one second from the start or something to have all position data be "ahead of time" with a well-known time offset. I dunno how the workflow would be. To edit the keyframes would be to add that missing second at the start again, edit whatever needs to be changed, and then remove the second at the start again. :S As long as all the position keyframes are ahead of the animation.

Is that reasonable or would the workflow be too strange to make that happen? If you think it's possible to do I could perhaps experiment with the plugin and see what I can come up with when I have the time.
Other things that needs to be in sync would be timelines speed + global speed. :/
 
Last edited:
For linear toy devices (which this plugin is made for) it tries to predict, based on 1 value (current axis input), the distance, speed and where to stop (min/max) based on earlier strokes. This works decent enough in most scenes. The override value just overrides the current axis input which drives this whole mess :)

Way back before timeline and when VamLaunch was new, I did some proof-of-concept code for keyframing animations. It had accuracy but was a lot of work setting up keyframes manually and with a VAM crashing constantly back then I gave up that path. This was before TimeLine and .var packages was a thing.

It all depends how much data you want to feed the toy. While position is one parameter, speed is another. At the end, I think it's easiest for the animator to just have to worry about the position.

The keyframing basically consisted of a position+timestamp. Where in the animation(time) would the toy end up (position). The rest could be derived based on this information, such as the speed.
One could perhaps think of a way to have 1 slider value controlled by timeline that when changed instantly (Curve type: Constant) would represent the next position. Now, it can't be a position where you want the device to be as it can't travel instantly at the speed of light to that position. But having a position representing a future timestamp with a well-known time offset. With a well-known time offset for the future position then speed could be calculated and distance for each new position where the device should move to next. Tricky, but would certanly work.

Do you think it's reasonable to set position keyframes like one second ahead of time? Perhaps it's possible to do in another timeline plugin instance on another atom that you can keyframe and set position based on the current animation and then you cut one second from the start or something to have all position data be "ahead of time" with a well-known time offset. I dunno how the workflow would be. To edit the keyframes would be to add that missing second at the start again, edit whatever needs to be changed, and then remove the second at the start again. :S As long as all the position keyframes are ahead of the animation.

Is that reasonable or would the workflow be too strange to make that happen? If you think it's possible to do I could perhaps experiment with the plugin and see what I can come up with when I have the time.
Other things that needs to be in sync would be timelines speed + global speed. :/
Unfortunately, I have never gotten good results with the prediction function. The motion is usually jumpy and inaccurate. The only good tracking I have ever gotten from VamLaunch is when it follows an animation pattern or oscillates. This has always been really disappointing to me.

My thoughts about driving VamLaunch with Timeline is to do what is essentially done by funscripts, which is to keyframe only the max and min values of each stroke. The speed is determined by the length of time between these keyframes. So, for example, if the Override Value (which is a slider) were to be driven by a variable trigger, and that variable trigger was controlled by keyframes inside Timeline, the motion of the Override Value would be moved progressively by the curve chosen inside Timeline. If it were assigned Linear keyframes in Timeline, the Override Value would move progressively in linear motion towards each keyframe value. So it would indeed move at the intended speed, no additional speed data would need to be added. But I also don't have a full understanding of the VamLaunch plugin, so perhaps I am missing pieces of information that would prevent this.

In response to your question: If there is a delay or offset needed for the plugin to "catch up" to the keyframes, then yes that shouldn't be a problem at all. I can simply use bulk actions to slide all the keyframes 1 second earlier, or however long is needed for the plugin to calculate the trajectory. My workflow for animating the keyframes would be like this: Move the animation forward gradually until it reaches the top of the thrust, set a keyframe. Move forward gradually until it reaches the bottom of the thrust, set a keyframe. If she pauses in a sitting position, wait until she's about to move again, then set another keyframe. It would take me maybe 1-2 hours to animate an entire scene this way. Totally worth it!
I understand that this approach might be a lot more complicated than I am thinking, but wow, it would be amazing if it worked.
 
I am not sure if intended or not, but i found out that the fps has a direct impact to the detection. a 30 fps scene will result in basically the worst detection, with jagged movements and threshold detection, while a 90 fps scene will have same jagged movement but better threshold detection
I know, that's just how it is. I didn't write majority of the code base so not sure what's causing it. You can compensate by adjusting the sample rate. Seem to work better with a lower sampler rate for some reason (20-40).

Any chance of kirroo keon support?
Others have reported to got this to work with Kiiroo Keon - I have not that device so can't confirm anything.
 
Unfortunately, I have never gotten good results with the prediction function. The motion is usually jumpy and inaccurate. The only good tracking I have ever gotten from VamLaunch is when it follows an animation pattern or oscillates. This has always been really disappointing to me.

My thoughts about driving VamLaunch with Timeline is to do what is essentially done by funscripts, which is to keyframe only the max and min values of each stroke. The speed is determined by the length of time between these keyframes. So, for example, if the Override Value (which is a slider) were to be driven by a variable trigger, and that variable trigger was controlled by keyframes inside Timeline, the motion of the Override Value would be moved progressively by the curve chosen inside Timeline. If it were assigned Linear keyframes in Timeline, the Override Value would move progressively in linear motion towards each keyframe value. So it would indeed move at the intended speed, no additional speed data would need to be added. But I also don't have a full understanding of the VamLaunch plugin, so perhaps I am missing pieces of information that would prevent this.

In response to your question: If there is a delay or offset needed for the plugin to "catch up" to the keyframes, then yes that shouldn't be a problem at all. I can simply use bulk actions to slide all the keyframes 1 second earlier, or however long is needed for the plugin to calculate the trajectory. My workflow for animating the keyframes would be like this: Move the animation forward gradually until it reaches the top of the thrust, set a keyframe. Move forward gradually until it reaches the bottom of the thrust, set a keyframe. If she pauses in a sitting position, wait until she's about to move again, then set another keyframe. It would take me maybe 1-2 hours to animate an entire scene this way. Totally worth it!
I understand that this approach might be a lot more complicated than I am thinking, but wow, it would be amazing if it worked.
I only have VamLaunch device to experiment with. It has limitations in various steps of the chain.
In order to have it synced with an animation going up or down, the toy must have the destination/position known and the speed known when sending the command to move the toy up or down in order for the toy to smoothly move together with the motion. The speed can't change mid-motion until the device has stopped and is ready for the next command, with the expection of changing direction (the VamLaunch is quirky at best). If the device hasn't stopped it will keep the speed from the last command to my understanding.

Having timeline send an override value using a linear motion would have the internals update a float variable over time. Where would it stop? The logic can't predict that. How far should the toy move using a linear motion from timeline when it doesn't know where it would stop? Can't be predicted. While this would be the optimal way for an animator this plugin can't use that sort of data :)

That's why the final position must be known ahead of time and my idea of that is that timeline have the "constant" curve type set and each time the "override value" is updated through timeline it does it instantly and it indicates a new keyframe position that's 1 second (or some well-known time-offset) into the future. It's to work around limitations.

I will experiment with this the coming months considering you might be interested to try it out in your future creations. :)
 
I only have VamLaunch device to experiment with. It has limitations in various steps of the chain.
In order to have it synced with an animation going up or down, the toy must have the destination/position known and the speed known when sending the command to move the toy up or down in order for the toy to smoothly move together with the motion. The speed can't change mid-motion until the device has stopped and is ready for the next command, with the expection of changing direction (the VamLaunch is quirky at best). If the device hasn't stopped it will keep the speed from the last command to my understanding.

Having timeline send an override value using a linear motion would have the internals update a float variable over time. Where would it stop? The logic can't predict that. How far should the toy move using a linear motion from timeline when it doesn't know where it would stop? Can't be predicted. While this would be the optimal way for an animator this plugin can't use that sort of data :)

That's why the final position must be known ahead of time and my idea of that is that timeline have the "constant" curve type set and each time the "override value" is updated through timeline it does it instantly and it indicates a new keyframe position that's 1 second (or some well-known time-offset) into the future. It's to work around limitations.

I will experiment with this the coming months considering you might be interested to try it out in your future creations. :)
Well, I've gotten both the Launch and the Handy working great with funscripts, and the only data those hold are a timestamp with a position value for when the toy is supposed to change direction. But there's a lot I don't understand about how this all works. I suppose it was worth a try. ?‍♂️
 
Well, I've gotten both the Launch and the Handy working great with funscripts, and the only data those hold are a timestamp with a position value for when the toy is supposed to change direction....
That is what I need timeline to emulate. Position data at certain timestamps. To avoid the toy lagging behind, the timeline must feed this data ahead of time with a well-known time offset. Like 1 second or something.

If I spend the time experimenting with support for this sort of feature, would you be willing to try it out at all at some point?
I would make some demo scene myself first to see if it works. But I won't spend time on something if I know it won't be used, I have other things to prioritize :)
 
That is what I need timeline to emulate. Position data at certain timestamps. To avoid the toy lagging behind, the timeline must feed this data ahead of time with a well-known time offset. Like 1 second or something.

If I spend the time experimenting with support for this sort of feature, would you be willing to try it out at all at some point?
I would make some demo scene myself first to see if it works. But I won't spend time on something if I know it won't be used, I have other things to prioritize :)
Yes, absolutely! I'd love to help. :)
 
Blazedust updated ToySerialController+VAMLaunch with a new update entry:

ToySerialController+VAMLaunch (update) v.12

* Now compatible with the AltFuta plugin. Females with the AltFuta plugin is now considered males. Removing the plugin makes them considered females again.
* The 'Refresh' feature is now run automatically as you change menus to simplify detection of female/male updates, making it less likely to be required to press (if at all). You can disable this feature in the bottom of the left side of the options by unchecking the "Auto 'Refresh' on Menu Changes" if you feel menu navigation becomes...

Read the rest of this update entry...
 
Great update, @Blazedust ! I was also following your conversation with @CuddleMocap about the notion of tracking as a funscript; this is something I suggested a few years ago, but the back end was not compatible at the time if I recall.

The idea of having recorded movements is EXACTLY what would make this all come together perfectly. I hope you two figure it out! :) I continue to regret not becoming a dev.
 
I have been using this as a session plugin for a while. Version 12 will not work now unless I reload the plugin. Never had this issue before. Thanks.
 
:) Nice. Just don't wait around for this, I might not have anything until March or April.
I too would be very interested in trying this new method out, I understand what @CuddleMocap is referring to with the funscripts and the way the Handy works with them. I have made a few funscripts for videos myself and understand the creation process. I even played around with multi-axis and made some multi-axis scripts back when my OSR2 was working

To avoid the toy lagging behind, the timeline must feed this data ahead of time with a well-known time offset. Like 1 second or something.
Don't forget that Timeline has an actual built-in Time Offset feature, so this could absolutely be used to add the delay needed to feed the toy the position and time between points it will need. If I'm thinking correctly, this time off-set could also be tweaked live real time to better sync the toys movements with the visual actions through the use of triggers and sliders and such.

I'm really hoping you can figure out this new method, I'd be eager to make a LOT of use of it. The concept of creating interactive live scripted scenes is incredible. I'd be more than happy, in fact I'm even down right requesting, to help test and work this stuff out.
 
A lot has changed in my life situation the past 6 months and I have no longer time for VAM and even less so for plugin development for VAM.
I simply don't have the time to do the RnD for a plugin to keyframe toy movement or any other plugin. Hopefully someone else can bring funscript or some other feature to sync toy movement with animations that has more time on their hands than me.
Thanks!
 
Last edited:
Back
Top Bottom