Not yet
What should I do with them tho?
I think I gonna make the action ones override the axes and make the view ones add vibration on L0
…
Actually here’s 0.10 with multiaxis days 4 and 5 I of course didn’t bother testing
Someone test then for me
Goodnight
Can´t really think of anything other then override axis and vibrations either, don´t really see any problems with vibrations for the second one, however the first one might be a bit more tricky, there are different cut-ins, something like the cut-in of a quick fast handjob would work nicely with overriding the action, but there are also cut-in of just her face or teasing nipples, both probably would also work better with vibrations rather then an override, that said i am almost certain it´s random what cut-in plays, so no idea if it can be written in a way, that it knows what to do depending on what cut-in shows up
I’ve dropped a couple of vids with recorded funscript to to TominMod ~ pixeldrain . And a version of MFP plugin that record them as well. Please review and say how bad it is. I literally can see it now.
Does OFS support SLR multi-axis format? (the {axes:[{id, actions}]} script)
If you have an AI artist friend who can depixelate assets with img-to-img on whatever the modern Pony model is, then yes, press Alt+F11, decen, drop to BepInEx\plugins\ModImages and it’ll show in game. And send here.
At a glance this is horrible. Though I need to load it onto an OSR to see how well it fares in action. I also got the feeling that your game’s frame rate might have impacted the result (the “gaps” where there’s no nodes seems to be caused by the game stuttering).
Can you tell me how to record script? I can’t seem to find the option in MFP (v0.10.0_multidays1-5)
Check pixeldrain album theres cs file where you may need to set _dev_saveScripts or whatever
MFW I notices I use 145hz monitor and update is not 16.6ms
MFW I compared the times I use with Unity Time. time and found Time. deltaTime is always 16.6
Just tried the mod and jeez this is terrific. @Dimava is truly the mad scientist here.
If you weren’t aware yet, this mod plays no script. It generates motions on the fly based on the live2d meshes. It is essentially the VaM controller plugins (e.g. TCodeSerialController, ToySerialController) but for Live2d Unity games.
This is such a revolutionary step. If you find another Unity game with Live2d in it, this mod may work. Worst case it serves as a way to output scripts which can be later integrated using EDI.
The issue I’ve noticed is that perhaps the scripts are too faithful to the Live2D that they don’t feel comfortable on a device.
There often are drastic, fast movements which makes the OSR2 moves like it went rabid (the speed limiter in MFP also doesn’t work here too so it becomes quite scary). I wonder if this can be addressed by implementing some kind of smoothing algorithm. I remember @Yoooi’s ToySerialController had something like this.
Some penetration scenes have rather short stroke length due to her movements covering only half of the penis. Instead of tracking the vertex on the actual tip of the penis, might wanna use one that is a little down there on the shaft.
For MFP I had to turn off the sync feature for this mod to work. I also noticed that in PolledUpdate mode things becomes extra smooth however the strokes are very short. If I adjust the offset or scale while the mod is active, MFP is bond to crash.
This is intentional
Values are scaled on the MFP plugin side
“Legacy” levels 6-20 currently use MinMaxClamp-ers set to the min/max value reachable in the level and scale that to 0-100 L0, you may try them for that
(and they update their min/max if the value goes out of bounds)
Currently they are in Inactive state where they don’t modify the value, but you may try setting them to Active if you wish
But that doesn’t solves the problem of type2 movements being boring - that’s why I heavily lean for R0(twist) there. L2/L3 could work as well but I don’t have those
I think I will add settings for what scale to use later, please propose some if you want them to be implemented faster
…
Actually you can just assign the scale on MFP? Or maybe not, as it’ll become -50-50 rather then 0-100 idk ¯_(ツ)_/¯
A slight problem is that is has it keep peaks
A single-frame +50 peak over a straight line will have to span 10 frames up and 10 frames down
Afaik it’s a deadlock when UI thread emits a message while ChangeScript(Dictionary<Axis, Script>) has started but not finished processing
Then UI becomes unresponsive
I do already async-lock my message handlers so Seek and Pause work fine but not other UI
Should I try to switch from PblishMessage to InvokeAction?
I did not manage to lock anything while spamming script changes and changing scale/offset values like @Falafel said.
The only thing I managed to lock was on your plugin connect:
You are starting the RunInterval task that calls SetScript and immediately after calling SetScript from UI thread. The first thread that calls SetScript will want to update the UI thread and so the dead lock happens.
The TryRunLocked part should be run in a separate task or ideally in the RunServer or RunInterval task.
The whole semaphore is not needed as far as I can tell.
You are only in UI thread in OnConnect, OnDispose and in HandleMessage.
Did you run it with the game on or without the game?
If you’ve tried without the game then it’ll obviously work (because MFP doesn’t update script on every tick, that happens only when the game(or testing html) is running)
Try this one in that case
Without the game but I modified your plugin to spam it anyways.
I think the demo does not work.
Why would it not, the whole execution is on your task thread when you call SetScript, you can see it on the right block in first screenshot. During your thread executing the UI can do other things.
The problem is probably that you are using PublishMessage in the properties setter that gets called from multiple threads and from the UI thread. And same thing will happen as I described in previous comment. One thread will change one of the properties that requires synchronization to UI thread, and at the same time UI thread also attempts to change a property in your plugin, but you added the TryRunLocked which will cause the UI thread to wait for the other thread causing a deadlock.
If you want to do some sort of synchronization of those messages, check how the abstract source handles the events, it uses a Channel<> to push the events to a queue, that then each source implementation handles on some other thread. Internal source for example uses the same thread for publishing and handling events, while others have a separate tasks for both.
So you could consume those events in OnInterval and update your properties from single thread only.
Amazing technology, good fun. Game is much more difficult when you are also struggling IRL I really feel bad for protagnist now.
I tried it with the Solace Pro, but MFP never recieved the full range of motion from Tomin mod. L0 always ranged from about 0% to 50%, so SolacePro would only use half of its modest range. None of the motion / smart limit settings seemed to help.
Eventually this aggresive AutoHome setting saved it:
It will give the SolacePro more ‘room to move’ between Tomin signals and feel more reactive to the anim/gameplay.