[Tease Program] Tease-AI Java (1.4)

[leezer3]

@FrozenWolf-
You've probably seen this, but I've submitted a PR to your integration branch. Started off just getting Gradle working elsewhere, but I've done some marginal hacky work to stop it throwing a black-screen / displaying unwanted stuff on various invalid image cases, which you / GodDragoner may be interested in.

The *better* way to do this (at least IMHO) would be to re-write the entire thing as a function with return status (e.g. Success, Invalid Image, RemovedImage, WebException etc. etc.) and an out variable for the returned file, so that callers can re-request or switch to a local image on failure.
Don't especially like using exceptions for flow control either, but that was what the original function used to trigger a re-roll of the image.

[FrozenWolf]

@FrozenWolf-
You've probably seen this, but I've submitted a PR to your integration branch. Started off just getting Gradle working elsewhere...

Thanks for the pull-request. I didn't have notifications set up for pull requests (I do now!) so I didn't see it.

The local-integration branch is just my local stuff that I'm keeping independent from GodDragon's master branch; it contains some other bits that aren't intended for merging with the master, such as the minimum-ui patch (that was suggested by candriver) and the change-typing-colour which is a tweak for my colour scheme. The gradle changes that you made look good though. I just crowbarred a basic gradle script together to get something that allowed me to build locally on Linux with the libraries that came with the original TAJ installation, all going in to the 'gradle' branch. One of the commits '7ef184cd - Add links to media directories', won't make much sense to anyone else. Well spotted on the missing properties file; I inherited the .gitignore file and hadn't realised that it excluded *.properties. What I'll probably do is patch up the 'gradle' branch and merge the update back into the 'local-integration' branch.

It's great that you got it building under Windows; I haven't used Windows for about six months now and every time I boot back into it there seems to be a stack of critical updates that need to be installed, and I've pruned most of the development tools that I used to have on there anyway.

I've done some marginal hacky work to stop it throwing a black-screen / displaying unwanted stuff on various invalid image cases, which you / GodDragoner may be interested in.
The *better* way to do this (at least IMHO) would be to re-write the entire thing as a function with return status (e.g. Success, Invalid Image, RemovedImage, WebException etc. etc.) and an out variable for the returned file, so that callers can re-request or switch to a local image on failure.
Don't especially like using exceptions for flow control either, but that was what the original function used to trigger a re-roll of the image.

There are some nice ideas there. Note that the error images from tumblr are not always the same size, it seems to depend on the resolution of the image that was requested. I was thinking of scanning the decoded image to see if the outer edge was that particular blue/purple colour.

If you have a look at the branch 'fortify-media-playback', you'll see the commit '5a0e0f06 - WIP - Fix media stability issues' which takes a bit of a sledgehammer to the MediaHandler. Really all it does is separate the responsibilities of each media type and solve some bugs along the way. I'm testing these changes out with TeaseAIJava-TestPersonality and so far it is stable, but I have many more tests to write before I'm happy with it. Once that's done, I'll most certainly come back to your pull-request to see what we can merge in, there's lots of good things we can help to improve in this area.

[leezer3]

That's interesting- Everything I've seen is the same size so far.
Possibly might depend on the blog in question and from there the CDN it's fetching it from or something of that nature.
Pixel reading would probably work to an extent, but it's too broad a brush for my tastes.

Fundamentally, I suspect that there are few enough of these though that we might as well just use the file length. Probably going to be cheaper. You could also start shutting this behind a URL switch, but that's making work for no real use.

Your branch just seemed the place most development was going on at the minute, and it's hacky stuff
Plus there was the fact that Gradle already half-worked there, rather than me trying to stop the thing exploding from scratch.

Really thogh, Gradle wasn't too hard to get going on Windows, biggest problem is that I'm a C# guy, and Java is just that little bit different....
Note that JavaFX is still broken for anyone else checking out (unless you dump it in the appropriate place)

[FrozenWolf]

Created a pull request to address the problem of favouring clothed pictures regardless of how long into the session you are:
https://github.com/GodDragoner/TeaseAIJava/pull/27

Originated from: viewtopic.php?p=298226#p298226

[FrozenWolf]

Created a pull request to help fortify the media playback.
https://github.com/GodDragoner/TeaseAIJava/pull/28

It's a big-ol' change that might take some time to review (sorry GD!). I've tested it a lot under Linux with the Spicy Personality and with my Testing Personality: https://github.com/FrozenWolf4887/Tease ... ersonality.

A rallying call to other developers:

Spoiler: show

The main bug that I cannot resolve (and may be related specifically to Linux) is any call to

playVideo

with a URL reference. For example, the Test Personality calls

playVideo('http://localhost:8000/Videos/testing-video1.mp4')

to play a video served from a local python HTTP server (

python3 -m http.server

). The video always plays fine, but about 50% of attempts, the MediaPlayer object issues no callbacks whatsoever to indicate that it's finished, and its status remains as PLAYING indefinitely. Calling stop() on the MediaPlayer object when it's in this state doesn't do anything either. This can cause TAJ to hang in situations where it's waiting for the video to finish.

Note that this problem is also present in the TAJ 1.3 release from 2020-12-14, although I wish I'd checked that two weeks ago rather than assuming it was something that I'd screwed up!

I've spent a crazy number of hours trying to research and track this down and I wonder if it's something specific to my platform. It occurs with both OpenFX 15.0.1 and OpenFX 16; I haven't tried other versions. I'm starting to see the test videos in my dreams now.

@leezer3 - is this something that you could try out since you have a good cross-platform setup? Perhaps it won't happen under Debian, or Ubuntu, or Slackware, or OpenSuSE, or anything other than what I've got.

[lotar232]

You can quite easily play a video from a file inside your personality code files even though I don't think that's optimal. I mean probably the best way to go about this would be to upload the videos to some video plattform and then stream them into TAJ with via a new feature.

I think my main challenge is latency of intervening calls while the video is playing.... I can watch a video, and mark in time say 50 places in video where I want to call some function (lovense vibrator or pishock, which themselves may make network calls)... but when I play the video in over time the accumulated delay of all those calls gets me out of sync and I need to replay it a bunch of times and iteratively "fixup" the delays.... Its probably impossible to set up a bunch or wall-clock based interupts, so I think I just need to stick to doing the manual fix-ups (or come up with some algorithm to reduce every nth delay by a second to stay in-sync)

I could add something like "GetVideoPlaybackPositionMillis()" to tell you how far into the video you are so you just need to "wait()" until the next desired timestamp. That would at least accommodate for the video startup time and for the general JavaScript latency in performing other operations. There would still be some latency as you say when performing the action when reaching the desired timestamp, but at least it wouldn't lose synchronisation.

(sorry for the late response... work blackhole ;) )

yeah, a function like that could be awesome... it would let me do something like:

startVideo()

while ( GetVideoPlaybackPositionMillis() < firstEventTime)
{sleepmili's(100);}
do_first_event;
while ( GetVideoPlaybackPositionMillis() < secondEventTime)
{sleepmili's(100);}
do_second_event;
...


would you be able to put it in anytime soon?

[FrozenWolf]

I think my main challenge is latency of intervening calls while the video is playing.... I can watch a video, and mark in time say 50 places in video where I want to call some function (lovense vibrator or pishock, which themselves may make network calls)... but when I play the video in over time the accumulated delay of all those calls gets me out of sync and I need to replay it a bunch of times and iteratively "fixup" the delays.... Its probably impossible to set up a bunch or wall-clock based interupts, so I think I just need to stick to doing the manual fix-ups (or come up with some algorithm to reduce every nth delay by a second to stay in-sync)

I could add something like "GetVideoPlaybackPositionMillis()" to tell you how far into the video you are so you just need to "wait()" until the next desired timestamp. That would at least accommodate for the video startup time and for the general JavaScript latency in performing other operations. There would still be some latency as you say when performing the action when reaching the desired timestamp, but at least it wouldn't lose synchronisation.

(sorry for the late response... work blackhole ;) )

yeah, a function like that could be awesome... it would let me do something like:

startVideo()

while ( GetVideoPlaybackPositionMillis() < firstEventTime)
{sleepmili's(100);}
do_first_event;
while ( GetVideoPlaybackPositionMillis() < secondEventTime)
{sleepmili's(100);}
do_second_event;
...


would you be able to put it in anytime soon?

It's not too difficult to do, probably just one day with testing, although I'd want to do it on top of pull-28 because that changes quite a few things in that area, so we might have to wait for a bit until GodDragon's had a chance to review it. In the interim period, you could create your own stub version of getVideoPlaybackPositionMillis() that provides the amount of time since the video *might* have started, i.e.:

startVideo()
videoStartTimeMillis = getCurrentTimeMillis();

while ( getVideoPlaybackPositionMillis() < firstEventTime)
{sleepmili's(100);}
do_first_event;
while ( getVideoPlaybackPositionMillis() < secondEventTime)
{sleepmili's(100);}
do_second_event;
...

function getVideoPlaybackPositionMillis() {
    return getCurrentTimeMillis() - videoStartTimeMillis;
}

[saderis]

Hi, I'm not sure what happened but when I'm trying to start the program it shows up like this

[GodDragon]

Created a pull request to help fortify the media playback.
https://github.com/GodDragoner/TeaseAIJava/pull/28

It's a big-ol' change that might take some time to review (sorry GD!). I've tested it a lot under Linux with the Spicy Personality and with my Testing Personality: https://github.com/FrozenWolf4887/Tease ... ersonality.

A rallying call to other developers:

Spoiler: show

The main bug that I cannot resolve (and may be related specifically to Linux) is any call to

playVideo

with a URL reference. For example, the Test Personality calls

playVideo('http://localhost:8000/Videos/testing-video1.mp4')

to play a video served from a local python HTTP server (

python3 -m http.server

). The video always plays fine, but about 50% of attempts, the MediaPlayer object issues no callbacks whatsoever to indicate that it's finished, and its status remains as PLAYING indefinitely. Calling stop() on the MediaPlayer object when it's in this state doesn't do anything either. This can cause TAJ to hang in situations where it's waiting for the video to finish.

Note that this problem is also present in the TAJ 1.3 release from 2020-12-14, although I wish I'd checked that two weeks ago rather than assuming it was something that I'd screwed up!

I've spent a crazy number of hours trying to research and track this down and I wonder if it's something specific to my platform. It occurs with both OpenFX 15.0.1 and OpenFX 16; I haven't tried other versions. I'm starting to see the test videos in my dreams now.

@leezer3 - is this something that you could try out since you have a good cross-platform setup? Perhaps it won't happen under Debian, or Ubuntu, or Slackware, or OpenSuSE, or anything other than what I've got.

Accepted. Need to look into the issue with the video playback. Can you provide example code?

Hi, I'm not sure what happened but when I'm trying to start the program it shows up like this

Uhm, that is really strange. What system are you running? Windows? What localization/language is windows set to? What Java version are you using?

[lotar232]

I could add something like "GetVideoPlaybackPositionMillis()" to tell you how far into the video you are so you just need to "wait()" until the next desired timestamp. That would at least accommodate for the video startup time and for the general JavaScript latency in performing other operations. There would still be some latency as you say when performing the action when reaching the desired timestamp, but at least it wouldn't lose synchronisation.

(sorry for the late response... work blackhole ;) )

yeah, a function like that could be awesome... it would let me do something like:

startVideo()

while ( GetVideoPlaybackPositionMillis() < firstEventTime)
{sleepmili's(100);}
do_first_event;
while ( GetVideoPlaybackPositionMillis() < secondEventTime)
{sleepmili's(100);}
do_second_event;
...


would you be able to put it in anytime soon?

It's not too difficult to do, probably just one day with testing, although I'd want to do it on top of pull-28 because that changes quite a few things in that area, so we might have to wait for a bit until GodDragon's had a chance to review it. In the interim period, you could create your own stub version of getVideoPlaybackPositionMillis() that provides the amount of time since the video *might* have started, i.e.:

startVideo()
videoStartTimeMillis = getCurrentTimeMillis();

while ( getVideoPlaybackPositionMillis() < firstEventTime)
{sleepmili's(100);}
do_first_event;
while ( getVideoPlaybackPositionMillis() < secondEventTime)
{sleepmili's(100);}
do_second_event;
...

function getVideoPlaybackPositionMillis() {
    return getCurrentTimeMillis() - videoStartTimeMillis;
}

oh,I can do this without additional TAJ support... Thanks! this works:


function wake_delay(milidelay){
currenttime=VIDEO_WATCH.getTime();
while ( currenttime< milidelay+videoStartTimeMillis)
{sleep(100,"MILLISECONDS");
currenttime=VIDEO_WATCH.getTime();
}
}


....

const VIDEO_WATCH = new StopWatch();


VIDEO_WATCH.reset();
VIDEO_WATCH.start();
playVideo("Videos/Spicy/Punishments/Extreme/Suffer to Get Out.mp4", false);
videoStartTimeMillis = VIDEO_WATCH.getTime();

wake_delay(57*1000);
//cage and shocker
//58
pishock(1,30,1,0);

wake_delay((1*60+11)*1000);
//1:11
pishock(1,30,1,0);

.......

[saderis]

Hi, I'm not sure what happened but when I'm trying to start the program it shows up like this

Uhm, that is really strange. What system are you running? Windows? What localization/language is windows set to? What Java version are you using?

I'm using windows 10, with english language, java openjdk-14.0.2_windows-x64

[GodDragon]

1.4 is now officially released. It includes a lot of fixes and adjustments mainly made my FrozenWolf. Thank you for your help investigating all these nasty bugs and hunting them down
It seems to be fairly stable so I feel good with releasing this build to everyone. It should deal with a lot of problems that people were encountering

[tytylion]

The link for downloading java 14 is broken. https://jdk.java.net/archive
Is there somewhere else we can get it or do we need an account now?

I assume 16 won't work :)

[FrozenWolf]

1.4 is now officially released. It includes a lot of fixes and adjustments mainly made my FrozenWolf. Thank you for your help investigating all these nasty bugs and hunting them down
It seems to be fairly stable so I feel good with releasing this build to everyone. It should deal with a lot of problems that people were encountering

Woohoo!

Note: To those upgrading from a previous version, please remove all of the files from the following directory:

    Images\System\Downloaded Images\*.*

This will clear out the cached downloaded images that were not downloading properly before and are invalid (showing as a black image).

[FrozenWolf]

The link for downloading java 14 is broken. https://jdk.java.net/archive
Is there somewhere else we can get it or do we need an account now?

I assume 16 won't work :)

OpenJDK 15 or 16 should work. Give it a try and let us know what happens